Older blog entries for mglazer (starting at number 394)

20 Jan 2003 (updated 4 Aug 2011 at 18:13 UTC) »

The WxPython LivePerson Replication is ahead of schedule and will initialy use PHP for server side processing then be ported to Zope as the testing expands.

The API looks good, the XMLRPC rind file is done, initial WxPython clients are completed, screenshots taken, the Javascript for the client has been schematisized now I will generate it via a PHP server side call.

So basically the manager opens the Python Client which displays realtime user stats to their website based on the javascript generated file from the same server.

A user can request 'help' and chat with available manager clients or the manager can initiate a 'help' dialog with the user, works both ways.

Zope will be much better in handling all of the small and constant server communications that are required for such as program but for development as of now we'll stick with PHP server side coms.

19 Jan 2003 (updated 4 Aug 2011 at 18:13 UTC) »

I finally got the QuickBeep API from KillerSite Productions.

The API is a XML-RPC P2P corporate IM system running on a Python Client using WxPython.

19 Jan 2003 (updated 19 Jan 2003 at 19:35 UTC) »
Session Based Hack Tracking

For a prevention of flood requests to a web site, we assume a unfriendly would request two pageviews per second.

So, our time interval to check for a friendly is 10 seconds and 20 pageviews or 2 pageviews per second.

If they request 20 pageviews within 10 seconds the system dies (exists) with a warning. After the time interval has been reset the user then has two additional attempts.

After the third warning that user's session is banned.

Here is some modifed session click tracking attack blocking.

session_start ( );

session_name ( 'hack_block' );

$time_interval = 10;

$strikes = 3;

$pageviews = 10;

if ( $_SESSION['banned'] == 1 ) die ( 'You are banned!' );

if ( $_SESSION['pageviews'] ) {

$_SESSION['pageviews']++;

} else {

$_SESSION['time'] = time ( );

$_SESSION['pageviews'] = 1;

}

if ( $_SESSION['pageviews'] >= $pageviews && ( time ( ) - $_SESSION['time'] ) <= $time_interval ) {

if ( $_SESSION['strikes'] ) {

if ( $_SESSION['strikes'] >= $strikes ) {

$_SESSION['banned'] = 1;

} else {

$_SESSION['strikes']++;

}

} else {

$_SESSION['strikes'] = 1;

}

die ( 'Too many requests.' );

}

if ( ( time ( ) - $_SESSION['time'] ) > $time_interval ) {

unset ( $_SESSION['time'] , $_SESSION['pageviews'] );

}

Haven't tried it yet but it should work.

Remember, this is sessions based which means single user based tracking which cannot track a concerted effort by multiple computers.

You always check the system's CPU use levels for flood requests.

19 Jan 2003 (updated 19 Jan 2003 at 17:20 UTC) »

I was thinking about what would be the perfect number of clicks per time interval that could be seens as an attacker.

Would 10 clicks in 10 seconds be overzealous?

Let's say, that if a user agent clicked ten times on your site within ten seconds should that be seen as hostile?

For now let's say yes, 10 clicks (pageviews not hits) within ten seconds is a hostile act, you store thier IP adde and block any future clicks would this be enough and would it interfere with regular freindlies?

An easy solution to halt but not block is to use timed banning of IPs.

so, if a agent has clicked 10 pageviews within 10 seconds he is halted by his IP for another 10 seconds. After the ten second freeze is up he gains access again but is marked as a first strike offender. If the abuse continue (three strikes and your out) eventually you outright ban the IP.

In summary, you use sessions to count pageviews per 10 seconds. If within a 10 second time interval 10 pageviews are clicked we halt that IP for another time interval period and mark him as a first time offender. When the halt time interval period is up the marked first offender is allowed in. By the third offense that IP is banned.

This is obviosuly a simple hack to prevent simple attacks, Sessions clearly do not take into accottn a concerted attack effort by more than one user agent. To track multiple users as a concert you have to use server side tracking that is not single user based such as sessions.

<hr />

I have finished by web admin shell UI templator. It uses 4 of my new templating tool classes.

1. The new simple template parser (only variable interpolation no dynamic macros)

2. Template layout control (uses table blocks and placeholder mappings) to accelerate template building.

3. Template sets (themes)

4. Template compiler class for the simple template parser class.

It's initial release will be for PHPortal-XPC lite 2.0.

The XPC package release will feature compiled templates, a basic administration UI of templates and the PHP class components referenced in the XPC templates.

I am also throwing in a PHP client side caching function which basically reloads the user's cache, if it exists, of the page requested if it has not changed from the user's cache.

The above all dramatically increases user load time at a phenomenal rate.

<hr />

My next project is one of two.

Either I will tackle the PHP code to binary and back to PHP using PGP style passphrases with public and private keys or my transactional emulation project.

The trans emul should be fun. It basically allows for saving changes, commiting changes, and rolling back changes on a object using simple logic and flat file temporary caches.

The basic idea of trans emul is to create two versions of an object and to cache each change along the way. Changes affect one version the user sees while rollbacks use the cached versions. Implementing file locking and version control beyond that is pretty easy as well.

WxPython Rules!

A easy way to prevent security hacks of web data submissions via POST || GET from flood requests or simple Ddos attacks is to use session based submission limits with time intervals.

if ( $_SESSION['count-atmps'] ) {

$_SESSION['count-atmps']++;

} else {

$_SESSION['interval'] = time();

$_SESSION['count-atmps'] = 1;

}

if ($_SESSION['count-atmps'] >= 3 && ( time() - $_SESSION['interval'] ) < 100 ) {

die ( 'To many login attempts, come back later.' );

} else {

if ( ( time() - $_SESSION['interval'] ) > 100 ) {

unset ( $_SESSION['count-atmps'] , $_SESSION['interval'] );

}

}

The above allows for three attempts with a 100 second interval. So, after three attempts the user agent cannot attempt a submissions request again until the 100 second time interval mark has past then they are allowed three more attempts.

A good idea might be to increase the time interval by itself on each time interval unset. This would increase the time interval between allowed submissions attempts. The more the user attempts and is timed out the longer each timeout becomes. For instance, ($int_val+$int_val) = 200; or to grow exponentially you can multiply ($int_val*$int_val) = 10000;

You can of course increase the number of allowed attempts and the time interval. To be strict you can always at some point outright ban the IP from any future attempts.

19 Jan 2003 (updated 4 Aug 2011 at 18:14 UTC) »
18 Jan 2003 (updated 4 Aug 2011 at 18:14 UTC) »

385 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!