代写代考 FIT3173: Web Application Security II

Running Example
• Consider a social networking site, GraceBook, that allows users to ‘share’ happenings from around the web. • Users can click the “Share with GraceBook” button which publishes content to GraceBook.
• When users press the share button, a POST request to http://www.gracebook.com/share.php is made and gracebook.com makes the necessary updates on the server.

Running Example

Running Example

HTTP POST Request

CSRF Attack
• The attacker, on attacker.com, creates a page containing the following HTML:
• When user visit attacker.com, the spam comment will be posted to user’s share feed, if the user is currently logged in on gracebook.com
• Attack would be successful if the user was previously authenticated to gracebook.com

CSRF Attack
• JavaScript code can automatically submit the form in the background to post spam to the user’s GraceBook feed.
• Similarly, a GET based CSRF is also possible.
• Making GET requests is easier: just an img tag suffices

CSRF Attack
always log out of web sites at the conclusion of your session!

Defence: Referrer
• The browser will set the referrer field to the page that hosted a clicked link

Problem: Referrer optional • Not included by all browsers
• Sometimes other legitimate reasons not to have it • Response: lenient referrer checking
• Blocks requests with a bad referrer, but allows requests with no referrer
• Missing referrer always harmless?
• Attackers can force the removal of referrer
• Exploit browser vulnerability and remove it
• Man-in-the-middle network attack

Defence: Origin Header
• Introduction of a new header, similar to Referrer.
• Unlike Referrer, only shows scheme, host, and port (no path data or query string)
• Indicate the site visited immediately prior to the request

Defence: Origin Header
• Instead of sending whole referring URL, which might leak private information, only send the referring scheme, host, and port.

Defence: Nonce-based Protection
• Recall the expected flow of the application:
• The message to be shared is first shown to the user on form.php (the GET request)
• When user assents, a POST request to share.php makes the actual post
• The server creates a nonce, includes it in a hidden field in form.php and checks it in share.php.

Defence: Nonce-based Protection

Legitimate Case

Legitimate Case

Attack Case

• Include a nonce in every link/form!
• Can use a hidden form field, custom HTTP header, or encode it directly in the URL
• Must not be guessable value
• Can be same as session id sent in cookie
• Frameworks help: Ruby on Rails embeds secret in every link automatically

Common Web Vulnerabilities
• Cross-Site Request Forgery (CSRF)
• Bad web site sends request to good web site, using credentials of an innocent victim who “visits” site
• Cross-Site Scripting (XSS)
• Bad web site sends innocent victim a script that steals information from an honest web site

XSS Overview • Site attacker.com provides a malicious script
• Tricks the user’s browser into believing that the script’s origin is bank.com • Runs with bank.com’s access privileges
• One general approach:
• Trick the server of interest (bank.com) to actually send the attacker’s script to the user’s browser!
• The browser will view the script as coming from the same origin… because it does!

• Stored XSS
Types of XSS
• the attacker stores the malicious code in a resource managed by the web application, such as a database
• Reflected XSS
• the attack script is reflected back to the user as part of a page from the victim site

Stored XSS

https://excess- xss.com/
1. The attacker uses one of the website’s forms to insert a malicious string into the website’s database.
2. The victim requests a page from the website.
3. The website includes the malicious string from the database in the response and sends it to the victim.
4. The victim’s browser executes the malicious script inside the response, sending the victim’s cookies to the attacker’s server.
A Practical Example

Stored XSS Summary
• Target: User with Javascript-enabled browser who visits user-influenced content page on a vulnerable web service
• Attack goal: run script in user’s browser with the same access as provided to the server’s regular scripts (i.e., subvert the Same Origin Policy)
• Attacker tools: ability to leave content on the web server (e.g., via an ordinary browser).
• Optional tool: a server for receiving stolen user information
• Key trick: Server fails to ensure that content uploaded to page does not contain embedded scripts

Reflected XSS

Echoed Input
• The key to the reflected XSS attack is to find instances where a good web server will echo the user input back in the HTML response

Exploiting Echoed Input
Browser would execute this within victim.com’s origin

1. The attacker crafts a URL containing a malicious string and sends it to the victim.
2. The victim is tricked by the attacker into requesting the URL from the website.
3. The website includes the malicious string from the URL in the response.
4. The victim’s browser executes the malicious script inside the response, sending the victim’s cookies to the attacker’s server.
https://excess- xss.com/
Another Practical example

Reflected XSS Summary
• Target: User with Javascript-enabled browser who uses a vulnerable web service that includes parts of URLs it receives in the web page output it generates
• Attack goal: run script in user’s browser with the same access as provided to the server’s regular scripts
• Attacker tools: get user to click on a specially-crafted URL. Optional tool: a server for receiving stolen user information
• Key trick: Server does not ensure that it’s output does not contain foreign, embedded scripts

For reflected XSS, in order to exploit it, the attacker must induce victims to visit his crafted URL
For stored XSS, this requirement is avoided
Having deployed the attack within the application, the attacker simply needs to wait for victims to browse to the page or function that has been compromised
Reflected Vs. Stored XSS
Usually this is a regular page of the application that normal users will access of their own account.

Objectives in exploiting XSS vulnerabilities are achieved more easily if the victim is using the application at the time of the attack
E.g. If the user has an existing session, this can be immediately hijacked In a reflected XSS attack:
Reflected Vs. Stored XSS
The attacker may try to engineer this situation by persuading the user to log in and then click a link that he supplies
Or the attacker may attempt to deploy a persistent payload that waits until the user logs in

In a stored XSS attack:
It is usually guaranteed that victim users will already be accessing the application at the time the attack strikes
Reflected Vs. Stored XSS
If the page concerned is within the authenticated area of the application, any victim of the attack must also be logged in at the time

Reflected Vs. Stored XSS
Stored XSS flaws are often critical to an application’s security
In most cases, an attacker can submit some crafted data to the application
and then wait for victims to be hit
If one of those victims is an administrator, the attacker will have compromised the entire application

Injection Defence
• Input escaping
• Escape untrusted input so it will not be treated as a command.
• Input validation
• Whitelist untrusted against a safe list
• Use less powerful API
• Use an API that only does what you want • Prefer this over all other options.

Defence: Filter/Escape
• Typical defence is sanitising:
• remove all executable portions of user-provided content that will appear in HTML pages
->
• escape ‘special’ characters.

• Bad guys are inventive: lots of ways to introduce Javascript; e.g., CSS tags and XML-encoded data:

]]>

Input Validation
• Instead of trying to sanitise, ensure that your application validates all
• headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters)
• … against a rigorous spec of what should be allowed.
• Example: Instead of supporting full document markup language, use a simple, restricted subset, e.g., markdown
• This only works for inputs that are easily restricted.

Use a Less Powerful API
• The current HTML API is too powerful, it allows arbitrary scripts to execute at any point in HTML.
• Content Security Policy (CSP) allows you to disable all inline scripting and restrict external script loads.
• Disabling inline scripts, and restricting script loads to ‘self’ (own domain) makes XSS a lot harder.

XSS vs. CSRF
• XSS attacks exploit the trust a client browser has in data sent from the legitimate website
• So the attacker tries to control what the website sends to the client browser
• CSRF attacks exploit the trust the legitimate website has in data sent from the client browser
• So the attacker tries to control what the client browser sends to the website

Rules: Verify, then Trust
• The source of many attacks is carefully crafted data fed to the application from the environment
• Common solution idea: all data from the environment should be checked and/or sanitised before it is used
• Whitelisting preferred to blacklisting – secure default • Checking preferred to sanitisation – less to trust

程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com