Open source security

1,456 views

Published on

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

No Downloads
Views
Total views
1,456
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Open source security

  1. 1. Open Source SecurityHow to get lots of security for a low, low priceRachel Engel
  2. 2. • Open Source Projects: Projects with frequent humanresource constraints• How to get good security with few resources throughsolid planning• Use SSL• SQL Injection• XSS• Secure Password Storage• CSRFAgenda
  3. 3. • Open source projects are done by volunteers• Is often really hard to get enough people, and to getthose people to work on specific tasks (bugs, lesstechnically in-depth features, build cleanup, qc,documentation, etc)• “Hey! Could you spend saturday going back and lookingthrough 100k lines of code looking for injection bugs?”• If you plan well, though, your project can be protectedagainst many attack classes from the start.Human Resource Constraints
  4. 4. • Security bugs are often expensive to fix because peoplefix them well after the application is already developed.• It’s many many times cheaper and easier to do it fromthe start.• Four specific classes of web security bug can be cheaplydefended against by planning well from the start.PlanningWell SavesTime
  5. 5. • If I could offer you only one tip for the future, SSL wouldbe it.The long-term benefits of SSL have been proved byscientists, whereas the rest of my advice has no basismore reliable than my own meandering experience. I willdispense this advice now.• Seriously. Front to back, SSL only. If people enter thewebsite via HTTP, redirect them to the HTTPS version ofthe site.• Globalsign offering free certificates for open sourceprojects!Use SSL (apologies to baz luhrman)
  6. 6. SQL Injection• Big flashy vulnerability• Primary vulnerability used by lulzsec hackers• On a technical level, SQL Injection is acompletely solvable problem if you plan well.
  7. 7. • Example ofVulnerable Code:• $string = “select * from table where field = ‘” +$user_input + “’;”;execute_statement($string);• Issue: If the user’s input contains valid SQL code, theuser can execute SQL queries of their own choosingagainst the database• This is how headlines like “50 BILLION PASSWORDSSTOLEN FROM CONGLOMCO” start.SQL Injection
  8. 8. • The issue is that the user input is used directly in theconstruction of the SQL query. If we separate the datafrom the query, the statement is no longer vulnerable.Enter parameterized queries.• $query = “select * from table where field = ?”;execute_parameterized_query($query, $user_input);SQL Injection
  9. 9. • $user_input is now treated as data separate from thequery. SQL injection vulnerability: fixed• Important note: it’s still possible to build parameterizedqueries using user data. Important that people knowwhy they’re using parameterized queries.SQL Injection
  10. 10. SQL Injection• Normally these vulnerabilities are found by attackersafter an application has already been built.• If you write your application from the start to useparameterized queries, your application will be secureagainst SQL injection attacks from the start, for noadditional time investment.
  11. 11. Cross Site Scripting (XSS)• It’s best to think of XSS as HTML/Javascript Injection• It happens when data received from users ends up beingused to construct HTML or Javascript directly (soundfamiliar?)• Used by attackers to impersonate users on the website.
  12. 12. Cross Site Scripting (XSS)• $username = webservice_input();$html = “<html> Hello, “ + $name + “<html>”;• The user can submit HTML instead of their name,causing the web page to do whatever they want.• Think of this in terms of a web forum. If the web forumpermits cross site scripting, everyone reading thecomments section ends up being served malware fromshady websites.
  13. 13. Correct Mitigations that are cheap• HTMLCharacter Entity Encoding: long name, simpleconcept.• HTML will render &gt as >. Write a function that appliesHTML character entity encoding to user input wheneverit will be reflected into a web page.• Other important characters to encode: “ > < & ‘ :• SessionCookies: apply HTTPOnly and Secure flags toyour session cookies• HTTPOnly ensures that cookies aren’t used by script,and secure ensures that cookies only go over SSL.
  14. 14. Correct mitigations (expensive)• Admittedly this mitigation for XSS is expensive, but it’simportant.• InputValidation: I’ve never seen > or & in anybody’sname (apologies to anyone named Kathe>in&• For every bit of user input, make sure that it has theexpected format/character set.• Note: this applies to Javascript as well. If user data getsinjected into Javascript, make sure that the input doesn’thave ‘ ; or /• This mitigation is less spendy if you’re aware of it.
  15. 15. Password Storage• Never try to roll your own password storage. It’s*really* hard.• First wrong answer: storing passwords in plaintext. Ifthe database gets lost, attackers have the userspasswords trivially.• Second wrong answer: Just apply a hash. Hackers havemulti-terrabyte tables mapping common passwords totheir SHA-1 and MD-5 hashes. You can download themfrom the web.
  16. 16. Password Storage• Take three: Include a 128 bit random number (salt) intoevery password hash$pw_hash = sha1($random + $password)• This is better. It still doesn’t take that long for attackersto build a rainbow table for a single salt, though.• Take four: Per-password salt. This is getting very close.Only downside now is it still doesn’t take that long to runMD-5 or SHA-1 a few million times to hash commonpasswords.
  17. 17. Password Storage• Doing it right: Use a per-password salt, and make thehashing process really slow.• The attackers need the hashing to be quick in order toattempt enough passwords for successful brute forcing.• Bcrypt: a hash algorithm designed to be tunably slow.You can say how many times you want it to run thealgorithm when hashing with it.• Implementations for Java, Python, C, C#, Ruby, Perl,PHP
  18. 18. Password Storage• If the hashing takes a few hundred milliseconds, userswill scarcely notice the slight increase in time, as thehash happens only once.• Attackers are trying to hash a million passwords forevery salt. A per-hash cost of a few hundredmilliseconds stops brute forcing attacks prettyeffectively.
  19. 19. Cross Site Request Forgery• Also known as hostile linking.• The user is logged into bank.com• The user visits http://super-sketchy-site.com/• The html at super-sketchy-site.com includes the imagetag below<imgsrc=http://bank.com/transfer?amount=100000000&destination_account=10123453462”>• One billion dollars is transferred to the attacker’saccount.
  20. 20. Cross Site Request Forgery• Really easy to defend against if you plan from the start.• We’ll tie the page that serves the user the moneytransfer form and the webservice that receives thetransfer request together.• $csrf_nonce = sha-2($hostname + $path + random());https://bank.com/transfer?amount=100&account=destination_account&csrf=$csrf_nonce• The webservice will know the csrf_nonce, as will thepage the user is using, but the attacker doesn’t.
  21. 21. Cross Site Request Forgery• Why planning really helps here:• The method above can really be written in an hour or so.If you do that at the start, and include it in every formrequest (GET and PUT) on your website, you’ll be safelyprotected against CSRF.• If you wait until the website is already built, it ends upbeing very expensive. You have to usually rewrite majorportions of the web application to completely defendagainst it.
  22. 22. • Use SSL Front to Back, Get Free Cert• SQL Injection: Use Parameterized queries• Cross Site Scripting: Build an output encoding function,use it everywhere, HTTPOnly flag, Secure flag• Password storage: Use BCRYPT or PBKDF2 and a per-password salt• CSRF: send sha2($hostname + $path +$random_number) in every requestTL;DR / Cheat Sheet
  23. 23. • Thanks to write/speak/code, and everyone here at theconference.• Rachel Engel• Principal Security Engineer at iSEC Partners• 14 years in the computer industry (eek)• rachel at isecpartners.com• Contact tritter at isecpartners.com if you’re in the nycarea and interested in security talks.ThankYou
  24. 24. UK OfficesManchester - Head OfficeCheltenhamEdinburghLeatherheadLondonThameNorth American OfficesSan FranciscoAtlantaNew YorkSeattleAustralian OfficesSydneyEuropean OfficesAmsterdam - NetherlandsMunich – GermanyZurich - Switzerland

×