Your SlideShare is downloading. ×
0
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
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

Break it while you make it: writing (more) secure software

2,243

Published on

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

No Downloads
Views
Total Views
2,243
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
54
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
  • Transcript

    1. Break it while you make it writing (more) secure software Leigh Honeywell HackLab.to [email_address] http://twitter.com/hypatiadotca
    2. About Me <ul><li>Co-Founder and Board Member of HackLab.TO
    3. Advisor to the SecTor Security Conference
    4. U of T student
    5. Malware Operations Engineer at a major anti-virus vendor (who I am not speaking as a representative of) </li></ul>
    6. Why I'm here <ul><li>To talk about the core security principles developers need to know
    7. To get you thinking like the people who will try to break your app
    8. To show some nifty tools
    9. Maybe to scare you a little?
    10. To get you breaking your own apps :) </li></ul>
    11. #3hotsecurewords <ul>There are three core “pillars” of information security: <ul><li>Confidentiality
    12. Integrity
    13. Availability </li></ul></ul>
    14. Confidentiality <ul><li>Only allow access to data for which the user is permitted.
    15. The user may not be permitted anything!
    16. Sometimes called secrecy or privacy
    17. There are real consequences for failing at this – PIPEDA, HIPAA, PCI-DSS, and various other acronyms. </li></ul>
    18. Integrity <ul><li>Ensure data is not tampered with or altered by unauthorized users. </li></ul>
    19. Availability <ul><li>Ensure systems and data are available to authorized users when they need it.
    20. Without this, the others don't matter.
    21. Anyone remember Friendster? </li></ul>
    22. Vulnerabilities
    23. Vulnerabilities A vulnerability is an error made in a program, causing unintended behavior of the program in a way that affects security negatively. FIRST defines a vulnerability as: “a bug, flaw, weakness, or exposure of an application, system, device, or service that could lead to a failure of confidentiality, integrity, or availability.”
    24. Vulnerabilities Examples of vulnerabilities: <ul><li>Weak passwords
    25. Insecure permissions
    26. Directory traversal
    27. Buffer overflows
    28. Cross-site scripting and request forgery </li></ul>
    29. Exploits
    30. Exploits An exploit is a specific example of triggering a vulnerability. If the vulnerability is a missile, the exploit is the warhead.
    31. Exploits Examples of exploits: Morris Worm Almost everything at http://www.milw0rm.com/ http://www.example.com/displayfile.php?../../../../etc/passwd
    32. Exploits Easy way to think about it: If typing “ perl –e ‘print “A” x 10000; ” makes it crash, you’ve found a vulnerability If you end up with this, you’ve got a working exploit: bash-3.00# id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest), 45(utmp)
    33. The Security Mindset <ul><li>How many security features are there in a grocery store self-check-out?
    34. How can you break each of them?
    35. What did they forget to think of?
    36. Bruce Schneier on the mindset: http://tinyurl.com/2sj365 </li></ul>
    37. The Security Mindset How many of you opened that tinyurl? What if I'd just dropped a Firefox 0-day on you?
    38. I didn't, don't worry. That would get me fired.
    39. This is why I suck at programming
    40. Finding Balance “Not all &quot;harmless failures&quot; lead to big trouble, but it's surprising how often a clever adversary can pile up a stack of seemingly harmless failures into a dangerous tower of trouble. Harmless failures are bad hygiene. We try to stamp them out when we can.” – Ed Felten, Freedom to Tinker http://preview.tinyurl.com/c6ewzv
    41. Security Architecture The OWASP Secure Coding Principles puts it thus: “ Security architecture starts on the day the business requirements are modeled, and never finish until the last copy of your application is decommissioned. Security is a life-long process, not a one shot accident.” http://www.owasp.org/index.php/Secure_Coding_Principles
    42. Right from the Start <ul>When starting a new application or re-factoring an existing application, you should consider each functional feature, and consider: <li>Is the process surrounding this feature as safe as possible? In other words, is this a flawed process?
    43. If I were evil, how would I abuse this feature?
    44. Is the feature required to be on by default? If so, are there limits or options that could help reduce the risk from this feature?
    45. (also from OWASP) </li></ul>
    46. Security in the Bones Software design, as well as implementation, must consider the three pillars of information security. Otherwise, you're going to fail.
    47. 10 Principles Minimize attack surface area Establish secure defaults Least privilege Defense in depth Fail securely Don’t trust services Separation of duties Avoid security through obscurity Keep security simple Fix security issues correctly The OWASP guide gives 10 principles for writing secure code:
    48. 10 Principles <ul><li>Minimize attack surface area
    49. Give the attacker the absolute minimum possible to work with when trying to discover an attack. By reducing complexity of an application, the number of possible vulnerabilities is also reduced.
    50. Establish secure defaults
    51. If a variable level of security is desired, have the default be high, and leave it up to the user to make the decision to lower it. This prevents “out of the box” insecurities. </li></ul>
    52. 10 Principles <ul><li>Least privilege
    53. Any component of a system should have only as much privilege as necessary to function properly. This is best known for permissions on user accounts, but also applies to software components.
    54. Defense in depth
    55. Adding on more security methods is a good thing, but they must approach the problem in different ways. </li></ul>
    56. Defense in Depth
    57. 10 Principles <ul><li>Fail securely
    58. A system should be designed with the idea of failing securely in mind. At any point, if something goes wrong, the system should not be left in a less secure state.
    59. Don’t trust services
    60. Even if external data is coming from a trustworthy source, give it the same level of validation as any input that isn’t trusted. </li></ul>
    61. 10 Principles <ul><li>Separation of duties
    62. System roles should be considered when giving out privileges. Administrators of a system generally aren’t also users; while some super-user privileges may be needed to run the system, administrators don’t necessarily need the ability to do anything.
    63. Avoid security through obscurity
    64. Security through obscurity isn’t real security. Use Kerckhoff’s assumption: the attacker knows all of the details as to how the system works. </li></ul>
    65. 10 Principles <ul><li>Keep security simple
    66. Simple things are harder to break. The least complex solution which achieves a goal is probably the better solution.
    67. Fix security issues correctly
    68. Any problem that is being fixed needs to be treated as an actual problem, and not a symptom. The fix must go through the entire security process the same as new code; a fix isn’t a real fix if it introduces new problems. </li></ul>
    69. Fix Security Issues Correctly It was in the news again days later, when it turned out the fix wasn't a fix.
    70. Common Vulnerabilities
    71. C? C++? <ul><li>Buffer Overflows (stack and heap)
    72. Read this, it's ancient but seminal: http://insecure.org/stf/smashstack.html
    73. Format String Vulnerabilities
    74. Integer Overflows
    75. Memory Management
    76. Race Conditions </li></ul>
    77. Tools <ul><li>http://www.owasp.org/index.php/Fuzzing
    78. http://en.wikipedia.org/wiki/Dynamic_program_analysis
    79. http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
    80. Don't turn off Valgrind unless you know what you're doing (o hai OpenSSL) </li></ul>
    81. Another OWASP List! Top Ten Most Critical Web Application Security Vulnerabilities 2007 Version
    82. A1 – Cross Site Scripting (XSS) XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.
    83. A1 – Cross Site Scripting (XSS) <script>window.alert(&quot;meow&quot;)</script>
    84. A1 – Cross Site Scripting (XSS)
    85. A2 – Injection Flaws Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s hostile data tricks the interpreter into executing unintended commands or changing data.
    86. A2 – Injection Flaws
    87. A3 - Malicious File Execution Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.
    88. A4 - Insecure Direct Object Reference A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
    89. A5 - Cross Site Request Forgery (CSRF) A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
    90. A6 - Information Leakage and Improper Error Handling Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.
    91. A6 - Information Leakage and Improper Error Handling http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
    92. A7 - Broken Authentication and Session Management Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.
    93. A8 - Insecure Cryptographic Storage Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
    94. A9 - Insecure Communications Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
    95. A9 - Insecure Communications
    96. A10 - Failure to Restrict URL Access Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.
    97. What next? http://www.owasp.org/index.php/Top_10_2007-Where_to_Go_From_Here
    98. Do some learning <ul><li>http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
    99. I can't speak highly enough of this project
    100. http://www.foundstone.com/us/resources-free-tools.asp
    101. Foundstone teaching tools (the “HacMe” series, in a variety of languages)
    102. http://tinyurl.com/hackarchive
    103. The Hacker Media archive – decades / terabytes worth of Defcon and other talks. </li></ul>
    104. Local AppSec Resources <ul><li>TASK - http://task.to , security user group
    105. OWASP Toronto Chapter - http://www.owasp.org/index.php/Toronto
    106. SECtor Security Conference - http://sector.ca , October 5-7
    107. HackLabTO - http://hacklab.to , free workshops and classes starting this spring </li></ul>
    108. Further Reading And just about everything on http://www.owasp.org Writing Secure Code, 2nd Edition: Michael Howard and David LeBlanc, Microsoft Press (2003) Hacking: The Art Of Exploitation, 2nd Edition: Jon Erickson, No Starch Press (2008)
    109. Thanks <ul><li>My coworker Seth Hardy, whose appsec notes I built on
    110. SecurityCompass for making awesome tools
    111. OWASP for being such a great resource </li></ul>
    112. Remember one thing! Never trust user-supplied data. Any Questions?

    ×