XSS Non - Persistent
The non-persistent(or reflected) cross-site scripting vulnerability is by far the most common type.These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the request.
Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection.A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.
A third-party attacker may easily place hidden frames or deceptive links to unrelated sites. They can cause victims' browsers to navigate to URLs on the vulnerable site automatically, say, to pick up their contact information—often completely in the background—and in such a case, the attacker can intrude into the security context that rightfully belonged to the victim.
XSS Persistent
The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.
For example, say the Golden Orchid is a dating website. Members scan the profiles of other members if they look interesting. Meanwhile, everybody's real names and email are kept secret on the server. The only time a member's real name and email are in the browser are when the member is signed in, and they can't see anybody else's.
Say, a hacker Mallory is a member, and he wants to figure out the real names of the women he sees on the site. To do so, he writes a program that runs on the women's browsers when they visit hisprofile. It knows where to get the real name and info, because Mallory read how the Golden Orchid web pages work. It then sends a quick message to his own server, which collects all of this information while he's watching football.
To do this, for the question "Describe your Ideal First Date", Mallory gives a short answer (to appear normal) but the text at the end of his answer is his program to steal names and emails. If it's enclosed in a <script> element, it won't show on the screen, it'll just run the program instead. So Alice is a member, sees the listing for Mallory. When she gets to the page with his answer to the First Date question, Mallory's program runs, steals a copy of Alice's real name, real email, address, and possibly even her password, directly from her machine, while she's visiting the dating website, and she never notices because there's very little to notice.
Persistent XSS can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of a client-side worm.
The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, etc.) that can be controlled by an attacker could become an injection vector.
Post a Comment