CS计算机代考程序代写 javascript database Java js Topic 4 – Client-Side

程序代写 CS代考 / database, javascript, Java代写代考, js

Topic 4 – Client-Side
COMP6443 – WEEK 8

COMP6443 – Week 3 – Injection

A NOTE ON ETHICS…
This course will teach both attacker and defender mindsets
UNSW hosting this course is an extremely important step forward.
We expect a high standard of professionalism from you, meaning:
Respect the property of others and the university
Always abide by the law and university regulations
Be considerate of others to ensure everyone has an equal learning experience
Always check that you have written permission before performing a security test on a system

COMP6443 – Week 3 – Injection

Client-Side Attacks

XSS
Content Security Policy
Reference

COMP6443 – Week 3 – Injection

XSS
Injection of malicious client-side code into user’s browser
XSS could lead to
compromise of session tokens
defacement of website
bypass CSRF protection
anything that could be done with JavaScript

COMP6443 – Week 3 – Injection

Inject malicious client-side code

COMP6443 – Week 3 – Injection

Types of XSS
Reflected XSS
Stored XSS
DOM-Based XSS

COMP6443 – Week 3 – Injection

Reflected XSS – workflow

COMP6443 – Week 3 – Injection

Reflected XSS – Details

COMP6443 – Week 3 – Injection

XSS Reflected Demo
Aim of the game: Steal that cookie.

COMP6443 – Week 3 – Injection

Reflected XSS – Bypass filters
Step 1: Bypass app’s XSS filters

COMP6443 – Week 3 – Injection

Step 2: Attacker prepares dummy malicious payload
Reflected XSS – Bypass filters
https://{app_url}/demo-xss.html?search=

https://{app_url}/demo-xss.html?search=%3CscRipt%3Ealert%28%22hi%22%29%3C%2FscRipT%3E

Showing search results containing:

COMP6443 – Week 3 – Injection

Reflected XSS – Bypass filters
Step 3: Upgrade dummy payload to actual payload

COMP6443 – Week 3 – Injection

Reflected XSS – Bypass filters
Step 4: Send the malicious payload to victim.
https://{app_url}/demo-xss.html?search=

Victim/Chrome BOT

COMP6443 – Week 3 – Injection

Reflected XSS – Bypass filters
Step 5: Steal the session cookie of victim

Victim Clicks on link

Stolen Cookie

COMP6443 – Week 3 – Injection

Stored XSS – workflow

COMP6443 – Week 3 – Injection

Stored XSS – details

COMP6443 – Week 3 – Injection

DOM-Based XSS – workflow

COMP6443 – Week 3 – Injection

DOM-Based XSS – details

COMP6443 – Week 3 – Injection

[DEFENSIVE] MAKE NO ASSUMPTIONS
Don’t trust user input. Before you use an input, validate it.
Don’t trust other systems you talk to. Validate all data you rely on.
Validate both format and value – attacks aren’t just semantic.

COMP6443 – Week 3 – Injection

[DEFENSIVE] What is untrusted input?
Any inputs received from:
Users
External Sources (API calls, 3rd party systems)
Any input that could be influenced by user (cookie, web storage, HTTP header values)
Database
Internal Sources
Config files that could potentially influenced by user or other systems
When you are unsure of a data source, treat it as untrusted data.

COMP6443 – Week 3 – Injection

[DEFENSIVE] Strategy
Validation could have two different techniques:

Blacklisting
Whitelisting

Sanitisation is the process of removal of unsafe HTML tags and attributes:

script
iframe
onerror
onload

Encoding is the process of converting user input to a safe string.

URL Encoding
HTML Encoding

COMP6443 – Week 3 – Injection

[DEFENSIVE] Validation
What level of trust do I need to have in each piece of input I’m using?
Allowlist input if you can
Denylist input if you can’t
Most languages have their own filters

Designated Library Validation
//Third Party content
var thirdPartySrc = ‘‘

//Allow-list
var clean = DOMPurify.sanitize(thirdPartySrc, {ALLOWED_TAGS: [‘b’]})

//Deny-list
var clean = DOMPurify.sanitize(thirdPartySrc, {FORBID_TAGS: [‘img’]})

COMP6443 – Week 3 – Injection

[DEFENSIVE] HTML Sanitisation
Always use well-accepted HTML sanitisation library.
Some of the libraries include*:
HtmlSanitizer for .Net
OWASP Java HTML Sanitizer for Java
SanitizeHelper for Ruby on Rails
DOMPurify for Javascript
Angular & React has built-in sanitisers
Always make sure the sanitiser is updated.
* As per recommendation from OWASP XSS Prevention Guide.

COMP6443 – Week 3 – Injection

[DEFENSIVE] HTML Sanitisation
Client-side building of HTML elements and assigning attribute values.
Accepting third-party APIs which are XML, JSON or any other markup format.
Accepting user inputs as HTML.

Manual HTML Sanitisation
//Third Party content
var thirdPartySrc = ‘” onerror=”alert(\’XSS Attack\’)”‘

//Create image element
var img = document.createElement(‘img’)

//Add property
img.src = thirdPartySrc

//Inject into DOM
app.appendChild(img)

COMP6443 – Week 3 – Injection

[DEFENSIVE] HTML Sanitisation
Manual sanitisation works great but it is not suitable for large number of elements and attributes created on demand.

Designated Library Sanitisation

//Third Party content
var thirdPartySrc = ‘‘

app.innerHTML = DOMPurify.sanitize(thirdPartySrc)

COMP6443 – Week 3 – Injection

[DEFENSIVE] Encoding

COMP6443 – Week 3 – Injection

HTML Elements – Encoded


<script>alert("hi")</script>

%3Cscript%3Ealert%28%22hi%22%29%3C%2Fscript%3E

HTML Entity Encoding
URL Encoding

COMP6443 – Week 3 – Injection

[DEFENSIVE] Safe coding practices
A deeper look at XSS prevention.

Write proper code…..

COMP6443 – Week 3 – Injection

[DEFENSIVE] HTML Attributes
Untrusted data into typical values like width, name, value, can rely on attribute encoding.
Complex attributes like href, src, style and any event handlers should be sanitise.
Any characters other than alphanumeric should be escaped.
Always use quotes for attributes values.

COMP6443 – Week 3 – Injection

[DEFENSIVE] JavaScript Values
Untrusted data should never end up in JavaScript execution context (e.g. eval).
Untrusted data can only be placed inside a quoted ‘data value’ after proper escaping.
Any characters other than alphanumeric should be escaped.

COMP6443 – Week 3 – Injection

[DEFENSIVE] HTML Style Property
Untrusted data should never land in CSS style data.
Untrusted data should always be escaped before placed in property value.
Any characters other than alphanumeric should be escaped.

COMP6443 – Week 3 – Injection

[DEFENSIVE] URL Parameter Values
When inserting untrusted data into URL ensure strict validation to prevent unexpected protocols for example:
javascript:
data:
Any characters other than alphanumeric should be escaped by URL encoding.
Always use quotes for attributes values:

COMP6443 – Week 3 – Injection

[DEFENSIVE] DOM Based Defence
Avoid using innerHTML and instead use innerText or textContent.
Avoid passing untrusted data into following methods:

element.innerHTML = “…”;
element.outerHTML = “…”;
document.write(…);
document.writeln(…);

COMP6443 – Week 3 – Injection

[DEFENSIVE] XSS in Angular Demo
https://stackblitz.com/angular/gkreynogqkn

COMP6443 – Week 3 – Injection

Content Security Policy (CSP)
Enforce loading of resources (scripts, images etc.) from trusted locations.
Effective against XSS, Clickjacking etc.
Options to deliver CSP:
HTTP header
HTTP element
CSP report only for monitoring

COMP6443 – Week 3 – Injection

Simple CSP
Simple policy with good security requires:
all resources are hosted in same domain
no inline or eval for scripts and style resources

Granular version

COMP6443 – Week 3 – Injection

CSP Nonce
arbitrary number that be used just once
base64 encoded
added to script tag attributes

COMP6443 – Week 3 – Injection

[DEFENSIVE] CSP against XSS
No inline code allowed

Inline code enabled by specifying SHA2 hash
Content-Security-Policy: script-src ‘sha256-hWEXbex0cd37bsd3bspvnrDseE53=’;

Move inline JavaScript to separate file

COMP6443 – Week 3 – Injection

[DEFENSIVE] CSP against XSS
Following constructs gets blocked by CSP

Related Posts