HTTP Parameter Pollution

>>>> New type of attack on web applications: Parameter Pollution

At the recent OWASP conference, the Italian security experts Luca Carettoni and Stefano Di Paola demonstrated a new way of manipulating web applications and tricking security systems: HTTP Parameter Pollution (HPP).

This form of attack essentially involves submitting the parameters in GET and POST requests in unusual form or order, or with unusual delimiters. A request like:

GET /foo?par1=val1&par2=val2 HTTP/1.1

will be processed in the normal way, while

GET /foo?par1=val1&par1=val2 HTTP/1.1

with two occurrences of par1 can result in various different server-side variable interpretations, depending on the web server's or application's parsing routine. According to Carettoni and Di Paola, this can cause the application to behave in an unwanted and highly unpredictable way and result in security issues.

Web application firewalls (WAFs) and server security extensions are also vulnerable to HPP attacks. While Apache's ModSecurity module recognises an SQL-injection attack like:

/index.aspx?page=select 1,2,3 from table where id=1

it fails to detect

/index.aspx?page=select 1&page=2,3 from table where id=1

say the security experts. HPP can reportedly also be exploited for launching Cross-Site-Scripting attacks (XSS) on web browsers. The XSS filter of Internet Explorer 8 is apparently among the components vulnerable to this kind of attack.

Carettoni and Di Paola recommend stricter filtering and URL encoding to counteract HPP. They also recommend using strict regular expressions in URL rewriting.

The Security Implications Of Google Native Client

This is a wonderful post from Matasano Security about the implication of Google Native Client. This post explains in detail on the difference between the Google Native Client (NaCl) and ActiveX.

Read it at Matasano Security.

Anatomy of a Cross-site Request Forgery Attack

So far, this is the best article to articulate our well-beloved Cross-site Request Forgery (CSRF) attack.

A Cross-site request forgery attack, also known as CSRF or XSRF (pronounced sea-surf) is the less well known, but equally dangerous, cousin of the Cross Site Scripting (XSS) attack. With XSRF, you make use of victim's browser to perform a transaction (GET or POST) on your behalf to the vulnerable site that pre-authenticated earlier.

In this article, it gives an example where how XSRF works in a POST situation, and provide a few suggestions for mitigation:

• Validate on Referer (not 100% recommended).
• Implement of "canary" in the form (typically a hidden input) that the attacker couldn’t know or compute.
• Implement ViewStateUserKey to makes ViewState more tamper-resistant.
  
• Remember that "POST-only" isn't aprotection for XSRF.

References:

• Anatomy of a Cross-site Request Forgery Attack
• CSRF Attacks and Web Forms
• Take Advantage of ASP.NET Built-in Features to Fend Off Web Attacks
• ViewStateUserKey makes ViewState more tamper-resistant

Left-click Vs. Right-click

>>>> From the page Left Click Right Click:

BSOD Survival Guide

If you don't know what BSOD is or never see this before, then see this.

Make sure you check this out if you often get BSOD.

Related posts:

• BSOD in Olympic opening.
• Change color for your BSOD.
• Manual BSOD.
  

Security Breach on Twitter

Twitter has now confirmed that there was unauthorised access to its administration interface. The French blog Korben has published screen-shots which show details of the accounts belonging to Ashton Kutcher, Lily Allen, Britney Spears and Barack Obama.

See more detail at Twitter blog and here.