Saturday, February 12, 2011

Attribute-based Cross Site Scripting (XSS): When Encoding Double Quote " is Not Enough

Analysis: Attribute Based XSS

It works when an attacker injects an XSS payloads at the following point ($__$):

<input type="text" name="search" value="$__$" />

Typical payload is  "><script>alert('XSS')</script> which results in:

<input type="text" name="search" value=""><script>alert('XSS')</script>" />

Armed with this information, security-aware programmers have begun to encode the double quote character (") as &quot; or %22. This results in:

<input type="text" name="search" value="%22><script>alert('XSS')</script>" />

And XSS fails.

However, they neglect to encode the single quote character ('). For the above example, whether single quote is encoded or not, XSS will not be triggered.

See the follow example .

<input type="text" name="search" value="Keyword" onclick="this.value='$___$' " />

XSS works when an attacker injects the following XSS:

<input type="text" name="search" value="Keyword" onclick="this.value='xss';alert('XSS');x='' " />

Lesson Learnt:

Encoding only double quote proves to be an incomplete protection against the attribute-based XSS.
The following characters must be encoded.

  1. White-Space characters (Tab /Line Feed /Carriage Return /Space )

    This protects XSS for input tag without double or single quote.

    <input type=text name=search value=$___$ >
  2. '
  3. "
  4. <
  5. >
  6. /


Wednesday, February 9, 2011

Vulnerability in Third-party components


In web app vulnerability scanning, vulnerability in third-party components are always missed by scanners as components reside in off-site domains.

There have been XSS vulnerabilities identified:

Lesson Learnt:

Manual testing and reviewing third-party components is necessary to detect vulnerabilities.  It's not worth to leak security flaws through buggy 3rd party components.

From Arbitrary DNS Query to DNS Proxy

Most of today's corporate networks allow arbitrary DNS query.
Similarly wireless access points which are controlled by HTTP user credentials allow arbitrary DNS queries.

Attackers can easily bypass this restriction by setting up their remote DNS-based HTTP/Socks proxy servers.The thing is the restriction is set only on HTTP Data not others. Attackers can set up covert channels with DNS, ICMP, POP3 and so on.

Sunday, February 6, 2011

Defcon 18: How I met your girlfriend | The discovery and execution of entirely new classes of Web attacks in order to meet your girlfriend.

How I Met Your Girlfriend: The discovery and execution of entirely new classes of Web attacks in order to meet your girlfriend.

Lessons learnt:

Samy did an excellent presentation on how he carried out.

  • PHP session hijacking via smart bruteforce guessing of PHP session cookies through the analysis of PHP source code
  • Cross Protocol Scripting, XPS, (Fooling browser into thinking a malicious web site connects to HTTP servers which in fact connects to arbitrary to SMTP/IRC, whatever an attacker ask it to). A DCC,, (DCC CHAT <protocol> <ip> <port>) trick was used in POST data.
  • NAT Pinning through XPS (XPS makes browser think victim connecting to another HTTP server and nat-ed/firewall routers think user connecting to IRC server [which makes routers to allow connections from that IRC server connect-back attempt] )
  • Using image onerror techniques to identify user routers
  • Once identified, attempting to login user router using default username and password via Iframe
  • Once logged-in, attempting to get router MAC address via XSS flaw in user's router
  • Once got MAC address, identify user location via Google Location Services (

secure configurations for Laravel - The PHP Framework

This framework is makes security simple to achieve.  Out of all non-default settings, the little following can be set to achieve higher secu...