Elusive Thoughts: Going The Same Way?

Intro

This article is about explaining the Session Fixation and Session Hijacking vulnerability impact and also do a post exploitation analysis of the methodologies used from organized crime. Many people, and by many people I mean Information Security Consultants, Security System administrators and Penetration testers tend to believe that Session Fixation/Hijacking is not so serious problem and when found in a Web Applications, when they report it they characterize it as low risk or when the Web Application is vulnerable to session fixation, they believe that when the session is not passed in the URL it cannot be used in an efficient way to attack the website.Well that is wrong, and I am sure about it because I have seen lots of my clients becoming victims from organized crime. I am also reminding you that if:

You become a Cross Site Script victim it might be difficult to detect the attack (especially if you allow concurrent logins).
You have a Session Hijacking event it is not traceable, which means that, in order to be successful the session hijacking you have to allow concurrent logins.

Well how do you protect your session fixation? Well that is easy to answer. With properly configured the server same origin policy and by not allowing concurrent logins (it is implied that you have to use random values per page, refresh the cookie after successful login and generate truly random or pseudo random but, not predictable cookies). You should also perform web user auditing and if possible feed the web user logs to an IDS/IPS device or a web application firewall. Most of the IPS/IDS devices or Web Application firewalls can understand a syslog like input, and your web or system administrator can probably do that.

The XSS/Phising Proxy Attack

When a Web Application is vulnerable to a) Session fixation attack (e.g. predictable cookie generation or no cookie refresh after login) or b) Session Stealing attack (e.g. XSS attack or Script Injection Attack e.t.c) the following conceptual representation attack scenarios are all feasible. See the following diagram:

In the diagram above you can see that initially the attacker sends an e-mail that hides either a link that forms a GET request when passed in the browser or a hidden html form or a Java script/VBScript) that forms a POST request when passed in the browser or a link that redirects the victim to the fake proxy site. Now these types of attacks are already implemented in the Social Engineering Toolkit (SET) and you can have a look if you want. The attacker can form a POST/GET request to forward the predicted/fixed or stolen session id or can use a Phi-sing site to alter the GET request sent by the victim to a POST request with a valid session.

Then if you use a single session of authentication:

If the session is predictable the attacker can hijack multiple users sessions.
If the session is stolen, but not predictable and refreshed the attacker can hijack a single user.
If the session is not stolen, not predictable and not refreshed the attacker can hijack a multiple users.

The Same origin policy

The Same Origin Policy permits scripts running on pages originating from the same site to access each other's methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites.

This mechanism bears a particular significance for modern web applications that extensively depend on HTTP cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions. A strict separation between content provided by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality or integrity.

History

The concept of same origin policy dates back to Netscape Navigator 2.0. Close derivatives of the original design are used in all current browsers and are often extended to define roughly compatible security boundaries for other web scripting languages, such as Adobe Flash, or for mechanisms other than direct DOM manipulation, such as XMLHttpRequest.

Origin determination rules

The term "origin" is defined using the domain name, application layer protocol, and (in most browsers) port number of the HTML document running the script. Two resources are considered to be of the same origin if and only if all these values are exactly the same.To illustrate, the following table gives an overview of typical outcomes for checks against the URL "http://www.example.com/dir/page.html".

Same-origin policy for DOM access

With no additional qualifiers, the term "same-origin policy" most commonly refers to a mechanism that governs the ability for JavaScript and other scripting languages to access DOM properties and methods across domains (reference). In essence, the model boils down to this three-step decision process:

If protocol, host name, and - for browsers other than Microsoft Internet Explorer - port number for two interacting pages match, access is granted with no further checks.
Any page may set document.domain parameter to a right-hand, fully-qualified fragment of its current host name (e.g., foo.bar.example.com may set it to example.com, but not ample.com). If two pages explicitly and mutually set their respective document.domain parameters to the same value, and the remaining same-origin checks are satisfied, access is granted.
If neither of the above conditions is satisfied, access is denied.

In theory, the model seems simple and robust enough to ensure proper separation between unrelated pages, and serve as a method for sand-boxing potentially untrusted or risky content within a particular domain; upon closer inspection, quite a few drawbacks arise, however:

Firstly, the document.domain mechanism functions as a security tarpit: once any two legitimate subdomains in example.com, e.g. www.example.com and payments.example.com, choose to cooperate this way, any other resource in that domain, such as user-pages.example.com, may then set own document.domain likewise, and arbitrarily mess with payments.example.com. This means that in many scenarios, document.domain may not be used safely at all.
Whenever document.domain cannot be used - either because pages live in completely different domains, or because of the aforementioned security problem - legitimate client-side communication between, for example, embeddable page gadgets, is completely forbidden in theory, and in practice very difficult to arrange, requiring developers to resort to the abuse of known browser bugs, or to latency-expensive server-side channels, in order to build legitimate web applications.
Whenever tight integration of services within a single host name is pursued to overcome these communication problems, because of the inflexibility of same-origin checks, there is no usable method to sandbox any untrusted or particularly vulnerable content to minimize the impact of security problems.

On top of this, the specification is simplistic enough to actually omit quite a few corner cases; among other things:

The document.domain behavior when hosts are addressed by IP addresses, as opposed to fully-qualified domain names, is not specified.
The document.domain behavior with extremely vague specifications (e.g., com or co.uk) is not specified.
The algorithms of context inheritance for pseudo-protocol windows, such as about:blank, are not specified.
The behavior for URLs that do not meaningfully have a host name associated with them (e.g., file://) is not defined, causing some browsers to permit locally saved files to access every document on the disk or on the web; users are generally not aware of this risk, potentially exposing themselves.
The behavior when a single name resolves to vastly different IP addresses (for example, one on an internal network, and another on the Internet) is not specified, permitting DNS rebinding attacks and related tricks that put certain mechanisms (captchas, ad click tracking, etc) at extra risk.
Many one-off exceptions to the model were historically made to permit certain types of desirable interaction, such as the ability to point own frames or script-spawned windows to new locations - and these are not well-documented.

All this ambiguity leads to a significant degree of variation between browsers, and historically, resulted in a large number of browser security flaws. A detailed analysis of DOM actions permitted across domains, as well as context inheritance rules, is given in later sections. A quick survey of several core same-origin differences between browsers is given below:

Note: Firefox 3 is currently the only browser that uses a directory-based scoping scheme for same-origin access within file://. This bears some risk of breaking quirky local applications, and may not offer protection for shared download directories, but is a sensible approach otherwise.
Corner cases and exceptions

The behavior of same-origin checks and related mechanisms is not well-defined in a number of corner cases, such as for protocols that do not have a clearly defined host name or port associated with their URLs (file:, data:, etc.). This historically caused a fair number of security problems, such as the generally undesirable ability of any locally stored HTML file to access all other files on the disk, or communicate with any site on the Internet.

In addition, many legacy cross-domain operations predating JavaScript are not subjected to same-origin checks; one such example is the ability to include scripts across domains, or submit POST forms. Lastly, certain types of attacks, such as DNS rebinding or server-side proxies, permit the host name check to be partly subverted, and make it possible for rogue web pages to directly interact with sites through addresses other than their "true", canonical origin. The impact of such attacks is limited to very specific scenarios, since the browser still believes that it is interacting with the attacker's site, and therefore does not disclose third-party cookies or other sensitive information to the attacker.

Workarounds

To enable developers to, in a controlled manner, circumvent the same origin policy, a number of "hacks" such as using the fragment identifier or the window.name property have been used to pass data between documents residing in different domains. With the HTML5 standard, a method was formalized for this: the postMessage interface, which is only available on recent browsers. JSONP and cross-origin resource sharing can also be used to enable ajax-like calls to other domains. easyXDM can also be used to easily work around the limitation set in place by the Same Origin Policy. It is a light weight, easy to use and self contained Javascript library that makes it easy for developers to communicate and expose javascript API's across domain boundaries.

Reference:

Pages

25/06/2012

Going The Same Way?