In this article we will learn about Website Hacking.

Introduction[What is Website Hacking]

In this installment of the Website Hacking series, we will look at how to minimize the damage caused by XSS attacks, as our web application may at some point become vulnerable to this type of attack (HttpOnly cookies will be discussed). We will look at a mechanism to circumvent the security provided by HttpOnly cookies, known as the Cross Site Tracing attack. We’ll also give a short example of packet sniffing, followed by a longer discussion of session hijacking and session fixation.

Fill out the form below to download the code associated with this article. Each piece of code to be included in the article is linked to one of the files with the following syntax: Code.php SNIPPET 5 or Code2.php SNIPPET 7, where the first value is the file where the piece of code is located and the second is the specific code , which must be inserted. Inside the code files are comments that show when each fragment starts and ends.

XSS damage minimization (HTTP cookies only)
If your website becomes vulnerable to XSS at some point, you probably know that your cookies would be exposed. An attacker can simply store the document.cookie value somewhere and use it for malicious purposes – for example – they can try to steal your session by looking for a session identifier in your cookies. As you know, the main difference between cookies and sessions is that cookies are stored locally on the user’s computer and sessions are stored on the server (usually the tmp folder, which you need to ensure is outside of the public folder and out of reach for normal user).

However, sessions work by storing an ID that associates a user with a specific session stored on the server, and this session ID (known as magic cookies or session keys) can be stored and passed to the server in a cookie.

Here’s one way to make sure that if someone can get your users’ document.cookie, they don’t get all the cookies you’ve saved for that user.

Read the following setcookie description below (taken from php.net)

[php]
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )
[/php]

The way to make sure that if an unauthorized person can run JavaScript on the clients they don’t get the cookie is to set the last parameter ($httponly) to true. This will prevent JavaScript from reading the cookie you are setting.

A sample cookie would look something like this:

[simple]
code.php SNIPPET 1
[/simple]

Then you can easily access it with PHP using something like this:

[simple]
Code.php SNIPPPET 2
[/simple]

Even better, there’s a way to make all your cookies HTTP-only:

You can set session.cookie_httponly to 1 in php.ini or force HTTPOnly cookies only for specific pages/scripts on your site by adding:

[simple]
Code.php SNIPPET 3
[/simple]

in the header of the page.

Another way to add an HTTPOnly (lower level) cookie is to set the header yourself:

[simple]
Code.php SNIPPET 4
[/simple]

Bypassing and preventing HTTP-only (XST) cookies
We have seen that HTTPOnly cookies do not allow access to cookies from JavaScript. However, a technique has been created to bypass this protection. It is known as XST or Cross Site Tracing Attack.

An attacker could target old browsers and write something like:

[simple]
Code.php SNIPPET 5
[/simple]

Then the traceData variable would hold the cookies it wants and other data about the request. However, in current browsers, the TRACE request method for AJAX requests is disabled by default (raises a security vulnerability).

Similar AJAX XST attempts should not work on clients running Firefox 19.0.2+ or Chrome 25.0.1364.172+

Therefore, it may still be useful to block tracking requests.

To disable it natively, you need to open Apache’s httpd.conf file and add the following line to it:

TraceEnable disabled

This would work on Apache versions > 1.3.34 or 2.0.55+ for apache2.

Another way to disable TRACE methods without changing the htpd.conf file is to change the .htaccess file and add:

[simple]
Disable_trace.txt
[/simple]

Note: mod_rewrite must be enabled for the fragment to work.

Packet sniffing

There are many sites whose client credentials are vulnerable to man-in-the-middle attacks. When you connect to public Wi-Fi, there could easily be someone in that restaurant sniffing incoming traffic. Here is an example of using Wireshark:

Firstly, we have applied an HTTP filter to only see HTTP requests.

Then we use Ctrl+F, search for a String and enter “POST” for value to only see the POST requests (in most cases, those contain user-entered data and frequently interesting ones).

Here we see a sample of unencrypted client/server communication after a registration form has been submitted.

A fix for that is using HTTPS (TLS/SSL).

Session hijacking/Session fixation

Assuming another vulnerability (such as XSS) is present, an attacker can see the users’ cookies and then figure out which one is the session ID (by default, on Apache servers, the session ID is carried in a cookie called PHPSESSID) and hijack the active session Below is an explanation of how this could happen, let’s say we have this login script and the login form in the same file (in a real application the accounts would be populated from the database).

We can see that in the upper left corner there is a paragraph with the text “User appears NOT logged in” before the user has been logged in.

Note: we have enhanced the form visually a bit with Bootstrap 3.

The code is as follows:

[plain]
Code.php SNIPPET 6
[/plain]

We do not implement an actual attack but check our session ID cookie:

Then we open the page in a browser that does not have any active sessions, start Tamper Data and submit the form with wrong credentials, but use the session ID of the actual logged in user.

The result is: we have hijacked the session of a legitimate user and appear logged in. (We do not get redirected, but as you can see we are logged in and there’s no wrong credentials statement appearing).

In fact, as you can see, we are not redirected to the member zone, so the code inside the if ($accountPass

$pass) conditional won’t run, but if we have code running in another block that depends on the logged in user or something, then an attacker could run the code inside and do whatever they want with the user code. account.

The first and least effective way to protect against such attacks is to set session.referer_check = yourDomainHere in php.ini or use ini_set to set it for a specific script. This way the session would only be set up if the set domain/path is a referrer (equivalent to looking up $_SERVER[‘HTTP_REFERER’] regex in a sense and not a very efficient method). Additionally, it does not accept multiple parameters. In some frameworks like CakePHP, multiple parameters are supported.

You should guard against XSS attacks as they can leak the session ID and lead to session hijacking. You should also use httpOnly cookies to remove JavaScript access to your cookies, possibly minimizing XSS damage and not leaking user cookies.

Another thing you can do is check that the IP address of the person who first logged in and the IP address of the person using the session are the same (they are expected to be the same).

First, we’ll make the following changes (check for a session hijack attempt, tell the user they’ve been reported, and send them an email):

[simple]
Code2.php SNIPPET 7
[/simple]

In our loop that checks that some credentials match, we also need to log the person’s IP address at the time they log in.

[simple]
Code2.php SNIPPET 8
[/simple]

And we edit the section where we display content only for logged in users to something like:

[simple]
Code2.php SNIPPET 9
[/simple]

We have logged in with Chrome as Kenny.

We use a different IP address and try to steal the session with the session ID cookie credentials using Tamper Data.

We get the following page:

It looks like the user is NOT logged in (we didn’t trick the script) and the screen shows a notification that a violation has been detected. And when we look at our email client, we get a message similar to this, but with the attacker’s full IP address written in the body of the email:

Session pinning is different from session hijacking because in session hijacking an attacker could capture or hijack the session cookie, but in session pinning the attacker provides the user with a session ID that is already set and when that user logs in to the server, assigns their data to the session An ID that is set by an attacker that would allow them to access the user’s session.

Related article:Certified Ethical Hacker study resources 2023

If you want to prevent session fixation, one way is to check the referrer (we already mentioned this). Another way is to shorten the time sessions are active from another php.ini setting (session.cache_expire).

However, what we recommend is that you generate session IDs frequently.

Assigning a new session ID ensures that the ID obtained by a potential attacker will not be useful because the user would be assigned a new session ID.

We can achieve this using the following snippet:

[simple]
Code3.php SNIPPET 10
[/simple]

Conclusion

We’ve explored some common exploits in this article, and we hope you’ll start implementing some of these security mechanisms into your future projects, if you haven’t already.

Sources:

1. MDLog:/sysadmin, “Apache Tips: Disable the HTTP TRACE Method”, Accessed 3/12/2014, Available at: http://www.ducea.com/2007/10/22/apache-tips-disable-the-http-trace-method/
2. OWASP, “Cross Site Tracing”, Accessed 4/12/2014, Available at: https://www.owasp.org/index.php/Cross_Site_Tracing
3. Stack Overflow, ‘What is PHP’s session.referer_check protecting me from?’, Accessed 5/12/2014, Available at: http://stackoverflow.com/questions/4863946/what-is-phps-session-referer-check-protecting-me-from/