Frame Injection

Frame injection is a relatively simple vulnerability that arises from the fact that in many browsers, if a web site creates a named frame, then any window opened by the same browser process is permitted to write the contents of that frame, even if its own content was issued by a different web site.

Exploiting Frame Injection

If the application is vulnerable to frame injection, then an attacker can exploit this using the following steps:

1. The attacker creates an innocuous-looking web site containing a script that wakes up every 10 seconds and attempts to overwrite the contents of the frame named main_display . The new content is hosted on the attacker’s site and contains Trojan functionality that looks identical to the normal content, but transmits any entered data to the attacker.

2. The attacker either waits for users to browse to his innocuous site, or uses some proactive means of inducing them to do so, such as sending emails, buying banner ads, and so on.

3. A user browses the attacker’s innocuous-looking web site. If the user is simultaneously using , or does so while the attacker’s site is being displayed in another browser window, then the attacker’s Trojan content will overwrite the frame main_display in the window. If the user continues using what appears to be the application, then any data he enters will be submitted to the attacker.

This type of attack bears similarities to phishing attacks in which the attacker constructs a cloned web site and seeks to entice unwitting users to access it. However, in the case of frame injection, the attack is more sophisticated and much more convincing, because the cloned content actually replaces the authentic content within a browser window whose URL still points to the genuine application.

If the application being targeted uses HTTPS, then the attack will still succeed, and the security padlock displayed by the browser window will continue to show the correct certificate for . This is because when a browser displays a frameset, the security information for the main window relates to the page containing the frameset, which in this case still originates from . Hence, even a well-informed user may not notice an attack of this kind.

Preventing Frame Injection

There are two available mitigations to frame injection vulnerabilities:

■ If there is no requirement for the application’s different frames to intercommunicate, remove frame names altogether and make them anonymous. However, because intercommunication is normally required, this option is usually not feasible.
■ Use named frames but make them unique to each session and unpredictable. One possible option is to append the user’s session token to each base frame name such as main_display.

NEXT is..JSON Hijacking………………………..,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,