Foiling hackers - Security experts

[gevensen]

I am working on a financial database and I am using 5 checks after login to foil hackers

 

1 - obviously $_SESSION must be set

2 - user in $_SESSION must be in database

3 - all authorizations passed in session must match the auth for user in database

4 - referal must come from my server

5 - each page is assigned a session referer code (encrypted filename) which must then match the http referrer

6- the session id is then regenerated

 

if any of the 1st 5 checks dont pass the user is automatically logged out and the session destroyed and an alert email is sent to the webmaster

 

my database password and username is extremely strong

 

my login page limits bad username and password attempts and blocks the ip ( for several invalid username AND password combos)

 

for multiple bad user OR password (everybody forgets sometimes) i was thinking about having capthca popup after 5 attempts

 

in your opinion is this a sound strategy?

[dzelenika]

What about SQL injection and XSS attacks?

 

I think

 

http://www.ow asp.org

 

is good (best) starting point for security themes

[gevensen]

yes i am using mysql_real_escape_string to foil my sql injection attacks

[gevensen]

also to address the cross site scripting  2 of the checks require the inquiry to come from my server domain and i pass a code thru sessions which is essentially the name of the script (index.php, login.php ect) where the referral came from

using http referal i then compare where the request came from and if it doenst match where the page came from the sesion is destroyed and the user is basically automatically logged out with no reason given

 

for example there is a list of acceptable referal pages for each called page

[PFMaBiSmAd]

'HTTP_REFERER' (your items 4 and 5 and the last post) is just a header that is easily faked (web proxy and bot scripts simply set it to match the domain being requested) and it cannot be relied on for any security purposes.

 

However, what you should do is store a value in a session variable that says a browser (or a bot script) has visited a particular page (i.e. make your own referrer session variable.) Then test on any dependent page that the session variable exists and has an acceptable value for the 'last page visited.' Unset the session variable or set it to a different value (a value that indicates the current page) on the dependent page to prevent multiple submissions to the dependent page (some bot scripts do use sessions and would visit pages in the correct order.)

[gevensen]

yes i have read the referer can be faked

 

thats why in a second check i think i am doing what you are recommneding

 

i set a encrypted (md5) session variable and then check that session variable against a whitelist of acceptable pages and then i unset set that session variable and when the page exits i set it again with the code for that page and the next page checks the passed code against that whitelist and on and on we go

 

i am also encrypting filenames to make it impossible to say try to call login.php or admin, delete or any of the common names

 

i have also implemented a neat little thing i found called bot-trap to catch web bots and ban there ip's in the last 2 days it has caught 3

 

it uses robot.txt to disallow and of course when the bot goes there anyhow it is blacklisted

 

'HTTP_REFERER' (your items 4 and 5 and the last post) is just a header that is easily faked (web proxy and bot scripts simply set it to match the domain being requested) and it cannot be relied on for any security purposes.

 

However, what you should do is store a value in a session variable that says a browser (or a bot script) has visited a particular page (i.e. make your own referrer session variable.) Then test on any dependent page that the session variable exists and has an acceptable value for the 'last page visited.' Unset the session variable or set it to a different value (a value that indicates the current page) on the dependent page to prevent multiple submissions to the dependent page (some bot scripts do use sessions and would visit pages in the correct order.)

[gevensen]

for those interested i also found a great blog on security today while doing a bit more research

 

http://www.acunetix.com/index.php

 

(if its ok i post the link i am not involved with them admin can remove if they deem innapropriate)

 

i am trying to get my security setup like a fortress before i proceed too much further in the project

[blaatschaap]

I am working on a financial database and I am using 5 checks after login to foil hackers

 

1 - obviously $_SESSION must be set

2 - user in $_SESSION must be in database

3 - all authorizations passed in session must match the auth for user in database

4 - referal must come from my server

5 - each page is assigned a session referer code (encrypted filename) which must then match the http referrer

6- the session id is then regenerated

 

if any of the 1st 5 checks dont pass the user is automatically logged out and the session destroyed and an alert email is sent to the webmaster

 

my database password and username is extremely strong

 

my login page limits bad username and password attempts and blocks the ip ( for several invalid username AND password combos)

 

for multiple bad user OR password (everybody forgets sometimes) i was thinking about having capthca popup after 5 attempts

 

in your opinion is this a sound strategy?

make little function that checks if the $_SESSION['username'] exists in the database

 

<?php
function checkuser($user){	
$query = mysql_query("select `id` from `users` where `username`='$user' limit 1");
if(!mysql_num_rows($query)){
return 'DENY';	
}
}

$check = checkuser($_SESSION['username']);
if($check == "DENY"){
return;
}

?>

~Blaatschaap

[pkedpker]

there is a attack i dont know how its called but someone can put your SESSION ID of being logged in into their cookie file and login as you!..

 

IDK if its possible but it should be since its saved clientside

[WolfRage]

That is called session fixation where they either steal or attempt to guess the session ID. This can be made more difficult by using sha instead of md5. Additionally using a system of sending other obfuscated or hashed cookies, then validate for each cookie not just the one. It is also a good idea to make sure they maintain the same user agent.

[SetToLoki]

i set a encrypted (md5) session variable and then check that session variable against a whitelist of acceptable pages and then i unset set that session variable and when the page exits i set it again with the code for that page and the next page checks the passed code against that whitelist and on and on we go

 

i am also encrypting filenames to make it impossible to say try to call login.php or admin, delete or any of the common names

 

i have also implemented a neat little thing i found called bot-trap to catch web bots and ban there ip's in the last 2 days it has caught 3

 

it uses robot.txt to disallow and of course when the bot goes there anyhow it is blacklisted

 

'HTTP_REFERER' (your items 4 and 5 and the last post) is just a header that is easily faked (web proxy and bot scripts simply set it to match the domain being requested) and it cannot be relied on for any security purposes.

I am not to clued up on all this but I have read sha1 is better than md5 - http://uk2.php.net/md5 read the first user post you come to, it explains why. just my 2 pennies anyway, good luck staying safe. (on a side note I hear if you wrap things in rubber it makes lots of things safer)

[Maq]

(on a side note I hear if you wrap things in rubber it makes lots of things safer)

 

* crickets *

[gevensen]

i am using the md5 to encode the filename not the password just to mess with the attempts that are made because we tend to make the filenames similar login.php admin.php deleteuser.php ect

login becomes a crazy filename so it becomes a little hard to guess what to try to hack which is merely just one aspect of hacker attacks

 

I am not to clued up on all this but I have read sha1 is better than md5 - http://uk2.php.net/md5 read the first user post you come to, it explains why. just my 2 pennies anyway, good luck staying safe. (on a side note I hear if you wrap things in rubber it makes lots of things safer)

[gevensen]

yes i am looking at regenerating the session id and perform my 5 checks every page change

im not sure how this will affect server performance

if all works well i will end up with a dedicated server down the road

its a SAS project (service as Subscription ) so it will not be open to the general public to browse around and play with

and all the scripts will be in one place not on anyone elses servers

 

That is called session fixation where they either steal or attempt to guess the session ID. This can be made more difficult by using sha instead of md5. Additionally using a system of sending other obfuscated or hashed cookies, then validate for each cookie not just the one. It is also a good idea to make sure they maintain the same user agent.