Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JoshuaDams]

I was incorrect in the name, it's not a "session" hi-jack, however your methods for stopping the session hi-jack Fail.   I've tested extensively and the only way to throughoughly stop the session hi-jack was by using a sha1 has method to encrypt the session and log users out if the sessions dont match.

The way this hack that I'm describing works is more of a csrf hack than anything i suppose, dno if it even falls into the Xss Category

This hack is used for more than just staffing ones self.  I've seen it upload shells and run queries through the display pic form.

The best way to prevent it is by using getimagesize() on your display picture output to verify that it is indeed an image.

Everyone is so focused on securing their input on preferances but few think to just secure the output.

The reason being is you can secure it into the database using htmlentities or strip_tags or a combo of both, but getimagesize wont work because when they "input" a url that is just what they are doing.  There is no "image" to check until the site calls the IMAGE to be posted.  So sanitize your input and output to stop this hack.  Still not 100% sure on how to approach stopping this same exploit in signatures BBCODE as it posts text and image so getimagesize would be difficult to imply into an [img tag]

[Hitman 15]

the image one if you have one that actually uploads a pic to your server can it still be used to get to be admin

[JoshuaDams]

The upload image one is not exploitable in that manner no.  However it to has it's downfalls.

For one, you have to make sure that what is being uploaded is safe, you dont want them uploading shells as then they can do anything they want, admin being the least of your worries.

Once you have that protection accomplished you have to make sure that this is the route you wish to take.  If you run a large game imagine how many images are going to be uploaded to your server.

5k members = 5k pictures if they just upload one.  Not to mention when they change images etc. 

[Spudinski]

I'm sorry if I'm being vague here, but where has this topic headed?
I still don't quite understand the principle you are explaining here, on the one hand you are going on about an image exploit trough HTML markup, and then you are redirecting your opinion to raw output? I just do not see the relevance here.

I, and I'm quite sure 98% of web developers don't filter their output, we KNOW what it is, we designed the application and the manner of output.
You only filter the input of users, yes, granted that there is allot of aspects within the term input, but it can be covered by merely a line of scripting - for each input, or actually not.

Headers should be filtered, yes.
Additionally, whenever a user enters anything to your website, it should be check for consistency.
I personally don't like to filter the input from users, I try to minimize the amount of data the user has to enter, it makes everything easier for me and the potential client.
Validation might be a bit more risky and hard to correct the perfect pattern, but when you know what you are doing, just doing regex validation on strings is much more convenient.


Now on to the topic again, can you please explain your scenario about the images in more - extensive, if possible - detail?

[JoshuaDams]

Without going into to much detail as I dont wish for some random person to see how and start exploiting games.....

A large percentage of the people here tend to go to blacklisting certain inputs, and making sure what the users "enter" is safe.

But few fail to realize that tho this stops "some" hacks it will never stop all. 

The safest and best way to do it, Assuming you have time, is to Secure it going in, and secure it where it's printed out.

A common example would be preferances and display picture.

A lot of users tend to use the preferances I set up a long time ago which makes sure that the url input entered is a .gif/.jpg/.png etc and anything else is kicked out an image "whitelist" if you will.   While I admit this no longer works properly at the time I was under the assumption this would work.

After extensive testing and fellowing with even better coders and hackers, i've come to the realization that it merely leads to a false sense of security.

The reason being, is you can validate that the url is an image on preferances, heck, you can even try and use getimagesize on the input.

The problem being here, on a url insert to display elsewhere, getimagesize does not actually get a chance to check a url to see if it's an image as it's not being output there.  So getimagesize would only work for an "upload" type form.

Now what if i have a free host set up somewhere where i've modified my .htaccess to transform .gif into .php

Now say I have a script on that free host that includes

Code: [Select]

staff_special.php?action=userlevel&ID=THEIRcurrentID&level=2
into some <?php ?> tags  save that file as w/e .php.

Now i go to the site i wish to attack and in the preferances bit where you put a url for a picture

i put my w/e.php file into the preferances and submit it as a gif

i.e  my file is  admin.php

i save it as admin.gif

now that will bypass most basic securities on the preferances and in all reaility the "input" is secure.
However, this file is then viewed on the viewuser page, oh i'm willing to bet the output bit is not secure.  so my .htaccess has changed the .gif to a .php file now and whenever a user views the page it re-directs them.

This is but a basic example, but imagine the danger here of what could be done with someone who knows what they are doing.

I'm not 100% how well my method works, but I now check all input to make sure it's a gif/png etc on preferances as well as use a preg_replace to stop xss crap.

Now on viewuser i validate that it's an image being output or exit the command and echo some text.

It just seems the more i look at the mccodes engine the more flaws i find. 

For example, I recently was shown a csrf hack for one of the item pages that i have yet to see a single person secure.   I was also informed their is one for register and one for login tho i havent "seen" them.

I know where the one other vulnerability on Register.php is and few seem to notice this

On register.php  you have 2 instances of $_GET['ref']   one is capitilized meaning that the abs to secure the $_GET['ref'] Will not work so you have to choices here


$_GET['ref'] = abs((int) $_GET['ref']) is already done.  Further down tho you have

$_GET['REF'] =

Now you can either A.

Change all $_GET['REF'] to $_GET['ref']  or B.   above the first $_GET['REF']  add $_GET['REF'] = abs((int) $_GET['REF']

Quick fix.

[JoshuaDams]

    * *****
    * Reputation Power: 29
    * Spudinski has no influence.
    * Online Online
    * Posts: 36
    *
    * I have cookies!
    *
          o View Profile
          o WWW
          o Email
          o Add Reputation
          o Personal Message (Online)

Re: Session Hijacking
« Reply #6 on: November 14, 2009, 10:03:03 AM »

    * Reply with quoteQuote

Just don't allow session ID's in the url, apache(mod_rewrite) and php can do this, both very good.
It's simple to write a script to check this, or just change your PHP configuration file.

in php.ini, change the values to these:
Code: [Select]
session.use_trans_sid 0
session.use_only_cookies 1

script acces;
ini_set('session.use_trans_sid', 0);
ini_set(‘session.use_only_cookies’, 1);
or write the script:
Code: [Select]
<?php

if (isset($_GET['PHPSESSID'])) {
    $requesturi = preg_replace('/?PHPSESSID=[^&]+/',"",$_SERVER['REQUEST_URI']);
    $requesturi = preg_replace('/&PHPSESSID=[^&]+/',"",$requesturi);
    header("HTTP/1.1 301 Moved Permanently");
    header("Location: http://".$_SERVER['HTTP_HOST'].$requesturi);
    exit;
}

?>

or .htaccess
Code: [Select]
<IfModule mod_rewrite.c>

RewriteEngine On
RewriteCond %{QUERY_STRING} PHPSESSID=.*$
RewriteRule .* %{REQUEST_URI}? [R=301,L]

</IfModule>

lol

Fail.

You really think that's going to stop session-hijacking? lol

[Spudinski]

What did I miss? Why do I fail?

[JoshuaDams]

Ooop, nothing other than it wont stop Session ID's in url lol.


I tried this and a few other techniques not posted here and had Vlad use his program over and over. 

W/o fail he continued to log on any account of his choice.

The only way to stop it was discovered by Zeddicus after a few experiments and guy hasnt been able to do it since.


You can add 1 or all 3 of those files and i bet money you can still enter the PHP_SESSID bit into url ^^

[CrimGame.com]

or why not use my way which originated from phpsec and zeddicus

session-hijacking-protection