L2 - Client-side Attack Flashcards
OWASP Risk Rating Methodology Equation
Risk = Likelihood * Impact
Steps in OWASP Risk Rating Methodology
Step 1: Identifying a Risk
Step 2: Factors for Estimating Likelihood
Step 3: Factors for Estimating Impact
Step 4: Determining Severity of the Risk
Step 5: Deciding what to Fix
Step 6: Customizing Your Risk Rating Model
Step 1: Identifying a Risk
Identifying a security Risk
– List from OWASP, SANS top 25 e.g
Step 2: Factors for Estimating Likelihood
- Skill Level
- Motive
- Opportunity
- Size
- Ease of discovery
- Ease of exploit
- Awareness
- Intrusion detection
Step 3: Factors for Estimating Impact
- Loss of confidentiality
- Loss of integrity
- Loss of availability
- Loss of accountability
- Financial damage
- Reputation damage
- Non-compliance
- Privacy violation
Step 4: Determining the Severity of the Risk
0 to <3 : low
3 to <6: medium
6 to 9: high
Step 5 : Deciding what to Fix
- The most severe risks should be fixed first.
- Not all risks are worth fixing.
- Some loss is not only expected, but justifiable based upon the cost of fixing the issue.
Step 6: Customzing Your Risk Rating Model
o Adding factors
o Customizing options
Cross-Site Scripting (XSS)
A client-side code injection attack allowing the injection of malicious code into a website
When do XSS happen?
XSS flaws occur when an application includes untrusted data in a web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript
Impact of XSS
It allows attackers to execute scripts in the victim’s browser.
- He can steal the user’s cookies, allowing for someone to use the website pretending to be that user.
- He can steal the user’s session, steal sensitive data, rewrite webpage, redirect user to phishing or malware sit
Types of XSS attacks
- Reflected XSS (non-persistent), where the malicious string originates from the victim’s request. (form field, hidden field, URL, etc…). The website then includes this malicious string in the response sent back to the user.
- DOM-based XSS, where the vulnerability is in the client-side code rather than the server-side code.
- Persistent (Stored) XSS, where the malicious string originates from the website’s database.
Reflected XSS Attack
- The attacker crafts a URL containing a malicious string and sends it to the victim (by various means e.g phishing email, an injected link in a vulnerable website).
- The victim is tricked by the attacker into requesting the URL from the vulnerable website.
- The vulnerable website includes the malicious string from the URL in the response.
- The victim’s browser executes the malicious script inside the response, sending the victim’s cookies to the attacker’s server.
Persistent XSS Attack
- The attacker uses one of the website’s forms to insert a malicious string into the website’s database.
- The victim requests a page from the website.
- The website includes the malicious string from the database in the response and sends it to the victim.
- The victim’s browser executes the malicious script inside the response, sending the victim’s cookies to the attacker’s server.
Source
A source is a Javascript property that contains data that an attacker could potentially control.
Sink
A sink is a function or DOM object that allows Javascript code execution or rendering of HTML.
DOM Based XSS
- The attacker crafts a URL containing a malicious string and sends it to the victim.
- The victim is tricked by the attacker into requesting the URL from the
website. - The website receives the request, but does not include the malicious
string in the response. - The victim’s browser executes the legitimate script inside the response,
causing the malicious script to be inserted into the page. - The victim’s browser executes the malicious script inserted into the page, sending the victim’s cookies to the attacker’s server.
XSS Prevention
Encoding - which escapes the user input so that
the browser interprets it only as data, not as
code.
Validation - which filters the user input so that the
browser interprets it as code without malicious
commands.
Cross-Site Request Foregery (CSRF)
A client-side attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.
Differences between CSRF and XSS
CSRF is restricted to the actions victims can perform. XSS, on the other hand, works on the execution of malicious scripts enlarging the scope of actions the attacker can perform
* XSS requires only a vulnerability, while CSRF requires a user to access the malicious page or click a link.
* CSRF works only one way – it can only send HTTP requests, but cannot view the response. XSS can send and receive HTTP requests and responses in order to extract the required data.
CSRF Prevention
- Use anti-forgery tokens in ASP.NET Core
- By including anti-forgery tokens in your application,two different values are sent to the server with each POST.
– One of the values is sent as a browser cookie
– The other is submitted as form data. - Unless the server receives both values, it will refuse to allow the request to proceed.
- Thus the server ensures that all legitimate requests must come directly from the client, not from an external source.