Advanced Web Security Topics

DZone 's Guide to

Advanced Web Security Topics

An excellent summary of clever, non-trivial hacks to watch for in your public-facing sites.

· Web Dev Zone ·
Free Resource

This post discusses web security issues that I've come across so far—thankfully, mostly by reading about them. It is a work in progress which I'll keep updating. The post title includes "advanced" because the topics discussed here involve clever, non-trivial hacks, which are novel at the time of their publication and often combine features with non-obvious consequences.

Using Wrong MIME Type in Images to Serve HTML

Abstract: An attacker uploads an image to a trusted website which contains HTML and JavaScript, but tricks the website to serve the image as an HTML document.

Image title

This first one comes from An XSS on Facebook via PNGs & Wonky Content Types [1] which gets the browser to execute HTML code embedded in an image. This attack uploads an image that contains HTML strings as user-contributed content and serves it with an HTML MIME type from the same domain as the compromised website. This exploit circumvents many server-side code injection checks since nobody checks for code in images. The exploited weakness here is that the website could be tricked into serving a user-contributed image with an HTML MIME type by appending the right suffix to the URL file name.

The truly brilliant part is the elaborate construction of a valid PNG image [2] which contains HTML. Browsers are very lenient when parsing HTML—they will just display everything they don't understand as text and interpret the rest, so an (otherwise) binary PNG with embedded HTML will render a lot of garbage alongside the HTML. That HTML can contain valid JavaScript which the browser will execute with the currently logged in user's domain cookies and credentials.

Stealing Secrets With User-contributed CSS

Abstract: Use a combination of CSS3 features to leak information to a 3rd-party server. Requires user-contributed CSS styles but no JavaScript.

This attack from Scriptless attacks [3] is remarkable because it can steal hidden information from the DOM like tokens from href links or hidden input fields without any JavaScript. It requires that a user can inject CSS into a website—a common feature of blog software. In short, it makes hidden information visible on the screen, then applies various fonts to that information. The dimensions of the newly rendered elements are probed with a CSS animation which leaks the dimensions to a server via an HTTP request (e.g. font or image) which contains the text dimensions as a URL parameter. The server can read that parameter and infer the original text from the numeric value. The details:

1) Attacker must somehow be able to inject CSS into the compromised website (e.g. user-styled blog or forum).

2) Make hidden information in the DOM (e.g. link parameters, hidden input fields) visible with advanced CSS3 selectors and the ::before or ::after pseudo elements. This will render strings that are normally not visible. For details, I recommend [4] and [5] under Resources at the bottom of the article. This step may replicate the to-be-leaked text multiple times since it needs to render it with different fonts (see step 3 for why).

3) Reference external CSS font files from a server you control. The authors call this a "dictionary attack". The width of the characters play an important role here because the combination of characters from step (2) will lead to a unique size of the rendered content. Disclaimer: I am not convinced this step produces a unique number (e.g. how could it distinguish AB from BA?), but I could imagine that multiple iterations of step (2) together with different fonts for each step might reduce the search space a lot. I also suspect that step (2) is executed multiple times on the same text with different fonts.

4) Surround the sensitive information with a DOM element which triggers a scroll bar and use the CSS "smart scroll bars" [13] feature: apply some CSS when scrollbars appear. That could be rendering an image content or another font file which triggers a request to the server. Note that for each size one could request a different URL.

5) Apply a CSS animation that resizes the container element from (3). The moment a scroll bar appears on the container, a new CSS rule is applied that loads a (non-existent) font file from the server we control. There is one such rule per container size with one unique URL per container size, so the size is effectively leaked to our server. From the leaked size we can infer the container's content.

Stealing Web Page Content by Tricking the Browser to Load the Private Page as CSS

Abstract: An evil website steals content from a trusted web page the user is logged into by tricking the browser to load the trusted web page as CSS. Requires that the attacker can inject a bit of text into the trusted website.

This one is a bit older and is possible because of lenient CSS parsing [6] and the fact that JavaScript is allowed to look into CSS declarations. I'm not sure to what extent this is countered browsers, I read conflicting statements about that on the interwebs. The exploit requires:

1) a victim, Victor

2) a website Webmail to which Victor is logged in which contains some private content. Webmail doesn't have to be open in a tab or window, as long as the user is authenticated and logged into Webmail via a session cookie.

3) a website example.com which the attacker controls

4) Victor visits example.com

5) The attacker must be able to inject some text into Webmail (e.g. by sending Victor some emails he can read in his Webmail) 

The exploit works like this:

1) Victor visits our malicious website, example.com

2) example.com contains a link HTML element which tries to load an external CSS style sheet. Only, instead of referencing a valid style sheet, it references a page that is Victor's inbox on Webmail. This will cause the browser to load the forum HTML as CSS and parse it. Not much harm so far.

3) The attacker is able to inject some text into Webmail that starts a CSS declaration before some sensitive text and ends the CSS declaration after the sensitive text. An example would be if we sent Victor a message at an early date with a subject: };.emailList{ and a message at a later date with the subject };. Now, everything in the inbox overview between the first and second email we sent can be interpreted as a CSS declaration.

Example of a compromised webmail inbox

4) When step (2) loads that CSS, because of the CSS parser's leniency, the browser will still be able to interpret the entire inbox as CSS, which will lead to (at least) the declaration of the .emailList class.

5) Since the attacker controls example.com, he can place JavaScript there that reads the cssText [8] property of the .emailList class and sends it to his server.

I remember reading about this exploit which keeps popping up over the years, but I can't find any illustrative references anymore. The articles showed how attackers are able to read a victim's webmail inbox by sending him two emails that contained CSS declarations in their subjects. Once the attackers lured their victim to their malicious website, the attackers were able to read the victim's inboxes as CSS declarations.

Angular Injection

Abstract: badly sanitized user input, rendered on server, leads to code execution in an Angular application in the browser

Injection attacks involve a malicious user submitting data which isn't sanitized properly and which is then later interpreted by a different part of the system. There are HTML injection attacks, SQL injection attacks, and JavaScript injection attacks. A rather new flavor targets browser templating frameworks like AngularJS [9].

The steps:

1) Malicious user submits some text T which Angular would interpret, e.g. {{alert('hello')}}

2) The server renders T as HTML on a page that also contains Angular code. Since there are no HTML/JavaScript tags like <script> in T, most server-side sanitizers wouldn't object T.

3) The browser renders the new HTML page which contains T. If the page runs Angular then it will pick up T and interpret it as JavaScript.

Gareth Heyes talks about Angular injection in detail [7].

In case you wonder why any sane web application would perform server-side rendering of user-submitted content (step 2): SEO or fallback strategies for feature-reduced clients are frequent use cases.

HTTP Injection

This type of attack also called HTTP protocol nesting or HTTP request smuggling [10] exploits weaknesses in HTTP protocol implementations of the participating devices.

The paper's authors discuss several real-world examples targeted against eponymous server software which lead to exploits like cache poisoning [11] or credentials hijacking. The exploits mostly involve a cascade of server software like a reverse HTTP proxy and a web server. An example:

Cache poisoning: a malicious client sends a nested request to a reverse web proxy with a web server behind it. The proxy parses the faulty request in a way that it thinks a URL U1 is requested while the web server parses the request in a different way and thinls that URL U2 is requested. The web server then returns the contents of U2, but the proxy stores that content under the URL U1. Hence, any further legitimate requests for U1 will serve the content of U2. The exploit works, oversimplified, like this:


Content-Length: 0

Content-Length: 123



Because of the conflicting Content-Length statements, the web proxy may consider the POST content to start at a different point than the web server behind it, so the web server may serve U2 but the proxy may store U2's contents under U1.

The authors discuss more vulnerabilities—a worthwhile read in any case!

Finding Out Which Sites a User Visited

A malicious webpage could find out in older versions of popular browsers which websites a user visited, fortunately that doesn't seem to be possible any more [12]. The "exploit" is simple and effective: the malicous webpage generates a list of links it is interested in. If the user has visited any of those in the past, the browser will render them in a different style. The webpage can query that style via a script and send the results away. Browsers have stuffed that hole with a combination of reporting fake values to scripts and limiting the amount of styling (e.g. you can't change any dimensions of the visited link, so querying container sizes won't work).


[1] An XSS on Facebook via PNGs & Wonky Content Types


[2] Encoding web shells in PNG IDAT chunks


[3] Scriptless attacks


[4] CSS attribute value selector


[5] CSS content attribute


[6] CSS data theft


[7] XSS without HTML: Client-Side Template Injection with AngularJS


[8] cssText Web API MDN


[9] AngularJS


[10] HTTP Request Smuggling


[11] Cache poisoning


[12] Privacy and the :visited selector


spring architecture ,xss ,web security ,css ,javacript ,devops

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}