Common Session Attacks (Session Fixation and Session Hijacking)


We developers use session protected functionality to restrict unwanted access, to provide security.  Do we know there are 2 very popular session attacks?

In the first type of attack, attacker can hijack any user’s session and use that same session to grab illegal privilege. This is called “session hijacking”.

In the second type of attack, attacker tricks to use her own specified session to victim which in turn disclose victims valuable details. In this way attacker fixes victim’s session, hence called “session fixation”.

In the both ways the main target is to use the same session which victim is using.

Procedure of Attack:

Except the initial step both type are same.

Session Fixation: This process starts before victim logs in. First atacker logs into the system and receive a valid session identifier (say sessionid = abcd). now attacker sets the victim’s session even bofore victim logs in.

Fixation

Following are 2 basic way to trick user-

http://anywebsite.com/<script>document.cookie=”sessionid=abcd”;</script>
http://anywebsite.com/<meta http-equiv=Set-Cookie content=”sessionid=abcd”>

Now if victim clicks on this type of link their session set to “abcd”. Now when victim logs in, same session id gets associated to his session.

Session Hijacking: In this process attacker try to grab a session which victim is using.

Following are few basic way to attack-

using cross site scripting –

<SCRIPT>alert(document.cookie);</SCRIPT>

Man-in-the-middle attack
Man-in-the-browser attack

Now the attacker impersonate as victim as she is using same session as victims session, and do whatever she wants.

Prevention:

Session Fixation:

-> Since Session Fixation starts before login, we can create a new session whenever an user logs in, hence preventing using of an existing session.
-> Use session_regenerate_id();

Session Hijacking:

Session hijacking cannot be directly prevented, however we can put steps in to make it very difficult and harder to use. Remember how difficult we can make it, attacker will leave and look for a softer target

-> Use a strong session hash identifier: session.hash_function in php.ini. If PHP < 5.3, set it to “session.hash_function = 1” for SHA1.
If PHP >= 5.3, set it to session.

hash_function = sha256

or

session.hash_function = sha512

-> “session.hash_bits_per_character = 5” in php.ini. When the attacker tries to guess the session identifier the ID will be shorter, but uses more characters.
-> Change the default session name from PHPSESSID to something else.
-> Save $_SERVER[‘HTTP_USER_AGENT’] in session and check in every request for user agent.

Defend attackers 🙂

References:
http://shiflett.org/articles/session-hijacking
https://www.owasp.org/index.php/Session_fixation
http://stackoverflow.com/questions/5081025/php-session-fixation-hijacking

Advertisements

New “unix Bash security hole”, deadlier than “Heartbleed”


images2A big unix bash hole (“Shellshock”) uncovered on 24thSep 2014, which can be used to take control of your unix based system.

Bash is the very powerful software to control unix based systems via command line. And if this powerful weapon reaches to an unwanted person, everything can be sacrificed.

The Department of Homeland Security’s United States Computer Emergency Readiness Team, or US-CERT, issued an alert saying the vulnerability affected Unix-based operating systems including Linux and Apple Inc’s Mac OS X.

Is your system vulnerable ?

As per an excellent write-up by RedHat, to check if your system is vulnerable, type below commands in bash.

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you see an output like

vulnerable
this is a test

You need a patch to fix it.

It is relatively easy to use this hole.

Tod Beardsley, an engineering manager at cybersecurity firm Rapid7, warned the bug was rated a “10” for severity, meaning it has maximum impact, and rated “low” for complexity of exploitation, meaning it is relatively easy for hackers to launch attacks.

Fix it!

US-CERT advised computer users to obtain operating systems updates from software makers. It said that Linux providers including Red Hat Inc (RHT.N) had already prepared them, but it did not mention an update for OS X. Apple representatives could not be reached.

To update it a similar type of command can be run

yum update bash

After a patch, if you run above command, you will find a output similar to

env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

For MAC users:
http://security.stackexchange.com/questions/68202/how-to-patch-bash-on-osx-in-wake-of-shellshock
Unlike Heartbleed, Shellshock doesn’t appear to have any easy solutions for average users right now. In most cases, it will be up to system administrators and software companies to issue patches.

Know more:

https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

http://www.reuters.com/article/2014/09/24/us-cybersecurity-bash-idUSKCN0HJ2FQ20140924

HOW  XSS attack handled by different PHP frameworks?


As we know PHP is Open Source, so we can play over it. It also has list of Frameworks to follow for web development.But, while doing development we have to take care about XSS attacks. Now, Question arrise 🙂

What  is XSS?

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in form of a browser side script, to a different end user. These attacks can occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

Basically, there are two types of XSS attacks:
1.) Stored: due to malicious code is saved on the server, and then sent to the end users, without proper encoding
2.) Reflected: due to malicious code is usually sent to the server in GET or POST parameters in http request, and the server returns that code in response, without proper encoding
It can be protect with :
a.) Filter input, escape output
b.) character encoding

How PHP FramWorks Handle XSS?
  • Yii– output escaping with integrated HTMLPurifier
  • Kohana2 – input filtering / global XSS filter
  • Kohana3 – input filtering, they recommend output escaping with HTMLPurifier, but it’s not included
  • CakePHP – offered a utility called Sanitize, but it is deprecated as of CakePHP 2.4 and will be removed in CakePHP 3.0
  • CodeIgniter – input filtering / global XSS filter
  • Zend Framework – custom output escaping
  • HTMLPurifier is a great solution when you need to display clean HTML that came from untrusted source, but for escaping every piece of data, which won’t be displayed as HTML, is overkill.
  • Global XSS filtering is a very bad idea, beacuse of the reason we mentioned above, you don’t know in which context the data will be used.
  • Sanitize : add() – Sanitize the data in the controller before saving
    beforeSave() – Sanitize the data in the model callback before saving
    afterFind() – Sanitize the data in the model callback after finding
  • OWASP has good security encoding library, but unfortunately, PHP version is not complete yet. They have a good reference for this matter. View
Example:
<body><?php echo htmlencode($untrusted_var); ?></data>
<input value=”<?php echo htmlencode($untrusted_var); ?>” />
While we can in most cases just use php’s htmlentities function.
So, it’s better to write custom wrapper functions, so we can change code only in one place if, for example, we want to add additional filtering or switch to another library.
function htmlencode($str) {
    $str = HTMLPurifier_Encoder::cleanUTF8($str);
    $str = htmlspecialchars($str, ENT_QUOTES, ‘UTF-8’);
    return $str;
}
This function will encode all html characters and prevent breaking the context.
If you need to write user data which contains html, HTMLPurifier will do the job.
I hope this will help you to understand XSS and to use it in your web development eailsy. 🙂
Enjoy Coding!