[code]Author: Nexus
-[ SUMMARY ]---------------------------------------------------------------------
0x01: Hello World
0x02: Introduction
0x03: About Authentications
\_ 0x03a: Cookies Hashing
\_ 0x03b: HTTP Referer
\_ 0x03c: CAPTCHA Image
0x04: One-Time Tokens
0x05: Conclusions
---------------------------------------------------------------------------------
---[ 0x01: Hello World ]
Welcome to a fresh new inaugural paper for the new season of the Playhack.net
Project! :) I'm really happy to see you back again and make our c00l project
be back!
Hope you'll enjoy this new short paper and i invite you to visit the whole new
project at:
http://www.playhack.net
Intake: actually nothing.. just a pair of cigarettes! :\
Shoutouts: all my shoutouts goes to my playhack m8s null, omni, god and emdel,
ofc to str0ke! NEX IS BACK!
-----------------------------------------------------------------------------[/]
---[ 0x02: Introduction ]
I already dealt with the Cross Site Request Forgery topic, but not too deep
regarding the possible solutions that web developers should adopt.
In these days i've been deeply involved in this topic during the coding of a
distributed web application which should warrant a good level of security for
user and most of all for the system's administrators (who are not that smart
though their tasks :P).
Considering this situation i had to consider each aspect and each possible
attack attempts that the applications could eventually suffer.
The one that gave me most problems to apply has been the Session Riding
(or CSRF, call it as you prefere) because there is no 100% certain way to
prevent that due to the concept that the attack fully stands on the users'
credentials.
If you don't really know what Session Riding is you should read the previous
paper reachable at the following link:
http://www.playhack.net/view.php?id=30
-----------------------------------------------------------------------------[/]
---[ 0X03: Possible Solutions ]
Ok, from here i must assume that you quite deeply know how a Session Riding
attack should work out :P
Let's just have a little and fresh resume..
Consider that a trusted user is logged into a website which permits him to
accomplish some important or confidential actions, an attacker wants to get
over a possible login attack (which often will be voided) and disfrut the
opened session of the user in order to realize some crafted actions.
The attacker in order to hijack the user's session will craft an appropriate
web page which will hide a javascript function that re-create an original
form but with fixed values, then he'll make the victim visit that page which
on load will submit the form to the remote action page which will accomplish
the request secretely (without the victim's aknowledge) confying on the user's
trusted credentials.
This is a as quick as simple explaining of how a Session Riding attack would
work out, the important question now is
"How do i prevent my users to be victims of that?".
Now you would probably consider the following solutions:
- Check some cookies credentials
- Check the HTTP Referer
- Use a CAPTCHA
With some tryouts you'll realize that these are not the most proper solutions
to adopt, let's see why one by one.
-----------------------------------------------------------------------------[/]
------[ 0x03a: Cookies Hashing ]
This first one could be a very simple and quick solutions to this problem
because the attacker should not be aware of the victim's cookies contents,
and cannot craft then a proper workaround.
An implementation of this solutions would work out in a way like following.
In some login file we create the Cookie related to the current session:
We use an hashing of the Cookie to make the form verified
And the action script would be something like following:
Actually this would be a fine solution to CSRF if we wouldn't consider the
fact that the user's cookie are a way easy to retrieve disfruting some XSS
flaw in the website (that we previousy saw they are not a rarity :D).
It would be more secure if we create and destroy a random cookie for each
form request that the user makes, but it wouldn't be very comfortable.
-----------------------------------------------------------------------------[/]
------[ 0x03b: HTTP Referer ]
The easiest way to check if the incoming requests are trusted and allowed, is to
disfrut the HTTP Referer and check if they come from the same website or from
a remote malicious page: this would be a great solution, but it falls due to
the possibility to spoof the referers and make them appear to be corrects.
Let's see why it's not a proper solution..
The following code shows an implementing example of HTTP Referer:
if(eregi("www.playhack.net", $_SERVER['HTTP_REFERER'])) {
do_something();
} else {
echo "Malicious Request!";
}
This check can be easily bypassed forging a fake HTTP Referer from the attacker's
script using something like:
header("Referer: www.playhack.net");
Or any other way to forge the Headers to be sent from the malicious script.
Since the HTTP Referer is sent by the browser and not controlled by the server
you should never consider this variable as a trusted source!
-----------------------------------------------------------------------------[/]
------[ 0x03c: CAPTCHA Image ]
Another idea that came out in order to solve this issue is to use a random CAPTCHA
image in every form which require the user to type in a textbox the generated string
and with that verify the integrity of the submitted datas and the credentials of
the user.
This solutions has been discarded some time ago due to the possibility to retrieve
the captcha image using the so called MHTML bug, which affected several versions of
Microsoft Internet Explorer.
You can find all the specific informations about this vulnerability from the Secunia
website:
http://secunia.com/advisories/19738/
Here's an extract from the Secunia's explanation of the bug:
"The vulnerability is caused due to an error in the handling of redirections for URLs
with the 'mhtml:' URI handler. This can be exploited to access documents served from
another web site."
In the same page you can find also a web test made from Secunia Staff.
Actually this bug is known to be solved with several patches released by Microsoft
for Windows XP and Windows Vista and with the release 6.0 of their own browser
Internet Explorer.
Even if actually it appears to be secure, the times brought to others possible
and theoretically more reliable solutions.
-----------------------------------------------------------------------------[/]
---[ 0x04: One-Time Tokens ]
Now let's explain the final solution i decided to adopt for my job: after having
dealt with all of these unreliable techniques i tried to write something different
and probably more effective.
In order to make the webforms safe from Session Riding (CSRF) i decided to make the
checking free from any kind of item that could be spoofed, retrieved or faked.
So i needed to create some one-time tokens that cannot be guessed or retrived in
any way and that after having accomplished their task would have been destroyed.
Let's start from the token value generation:
The uniqid() PHP function allows the web developer to get a unique ID from the
current time in microseconds, which is quite good in order to retrieve a value
that won't be repeated again.
We retrieve the MD5 hashing of that ID, and then we select 8 characters from that
hashing starting from a random number <=24 (strlen($hash)-8). The returned $token variable will retrieve an 8-long randomized token. Let's now generate a Session Token which will be used later for the last check:
With this function we call the gen_token() function and use the returned token
to copy his value into a new $_SESSION variable.
Now let's see the function that will start the whole mechanism and that generates
the hidden input for our form:
\n";
}
?>
As we can see this function just call the gen_stoken() function and create the
HTML code for the hidden input that will be included in the web form.
Let's now take a look to the function that make the check of the Session Token
with the submitted hidden input:
This function check the existance of the $_SESSION[STOKEN_NAME] and of
$_REQUEST[FTOKEN_NAME] (i used the $_REQUEST method in order to accept both GET
and POST methods from the form) and check if their values are the same: if they
are the submitted form is authorized.
The important point of this function is that at every concluding step the tokens
get destroyed and will be recreated only at next webform page call.
The use of these functions is really simple we just need to just add some additional
PHP nstructions.
This is the webform:
And this is the resolving script:
As you can see is really simple to implement such a check and it should protect
your users from being hijacked by attackers and avoid to get your datas
compromised.
-----------------------------------------------------------------------------[/]
---[ 0x05: Conclusions ]
Let's conclude this short paper saying that there is no 100% way to be secure
that your web application is completely safe, but you can start avoiding the
most common attacking techniques.
Another point that i'd like to make you focus on is that a web developer SHOULD
NOT forget of general applications faults (like XSS Browser Bugs ecc..), it
would be a great mistake not considering them as a potential threat for your
users: you should always keep in mind everything that could compromise your
application's integrity, security and interoperability.
Cya!
nexus
(The above PHP codes were taken from the Seride project, hosted at
http://projects.playhack.net/project.php?id=3)
-----------------------------------------------------------------------------[/]
\======================================[EOF]=====================================/
[/code]
