Bridging the gap - Security and Software Testing

1,375 views

Published on

When performing a security testing, I often sit in a room with other QA and Software testers.
During that time, it is likely I receive questions such as: "Roberto, are you hacking this? Are you breaking
this again? What exactly are you testing?"
Whi l e talking to them I realise there is an information gap between us, especially when they share
information which is essential for my testing and crucial to identify security vulnerabilities.
After a good number of security tests, I came to a conclusion that people in our industry do not realise that
software testing and security testing have a lot to share.
This talk intends to reduce that information gap and provides an introduction to security software testing,
methodologies, and most importantly offers some food for thought to stimulate synergy between security
and software testers

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

  • Be the first to like this

No Downloads
Views
Total views
1,375
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Bridging the gap - Security and Software Testing

  1. 1. Bridging the Gap - Security andSoftware TestingRoberto Suggi LiveraniANZTB Test Conference - March 2011 1
  2. 2. Agenda Roberto, what test are you doing? Is this a defect, vulnerability or both? What can we do to improve things? 2
  3. 3. About Me Roberto Suggi Liverani Principal Security Consultant - Security-Assessment.com  roberto.suggi@security-assessment.com  http://www.security-assessment.com Founded OWASP New Zealand Chapter  http://owasp.org/index.php/owasp_new_zealand Research topics:  Black SEO  Firefox Extensions  Bug discovery  Blog: http://malerisch.net Twitter: https://twitter.com/malerisch 3
  4. 4. Part IRoberto, what test are you doing? 4
  5. 5. What do I do for living (and fun) Hack almost everything  Web Applications, Software, Networks, etc Experience  From small companies to large enterprises Findings bugs  Not just my work, it’s also my passion 5
  6. 6. Security Testing Type of assessment  Black Box  Grey Box  White Box Type of services  Web application intrusion testing  Source code review  Software testing Scope  Discover security bugs  Provide recommendations 6
  7. 7. Prerequisites NO QA = NO Security Testing  Target software/application must be 100% functional  A correct QA process ensures reliable results The environment must be stable during testing  No testing while changes occur  A “confirmed” security issue must be reproducible The real world  Applications haven’t had through QA testing  Functionality issues (defects) often found 7
  8. 8. Security Testing Process  Information gathering  Follow “hacker” instinct  Spot vulnerability before starting testing Follow methodologies  Web Application  OWASP Testing Guide  Software testing  The art of software security assessment  Exploiting software 8
  9. 9. Tools Web hacking  Web Proxies  Web Scanner Frameworks  Browser + Extensions/Add-ons  Manual testing Software testing  Disassembler and debugger  Extensions + Plugins  Fuzzing tools Source code review  Static analysis tools 9
  10. 10. What do we find? Common vulnerabilities in web applications  A1: Injection  A2: Cross-Site Scripting (XSS)  A3: Broken Authentication and Session Management  A4: Insecure Direct Object References  […] Frameworks  PHP  Java  .NET 10
  11. 11. Bugs In Software Memory corruption bugs  Stack/Heap buffer overflows Other bugs  Filter controls bypass Where?  Some examples from our research:  Browser and browser plugins  Internet Kiosks  File Formats (e.g. chm)  MS Office Products 11
  12. 12. After Testing Reporting  Exec/tech overviews  Details section  Recommendations Classification and severity  Type of vulnerability  Level of exploitability Discussion with clients 12
  13. 13. Ideal Approach Ideal approach  Security should be a priority in early phases  Security must be a component of every project  From the initial stage to production Changes in the industry  Some of our clients are moving in this direction  New project:  Ask us - “What do you think?”  Recommendations can help avoid serious design flaws 13
  14. 14. Part IIIs this a defect, vulnerability or both? 14
  15. 15. A defect or a vulnerability? Definition  defect = potential vulnerability Defects can:  Hide an underlying vulnerability  Have security implications (and so it is also a vulnerability)  Lead in the discovery of a vulnerable associated component Strategy prior testing  Ask for more info from QA testers 15
  16. 16. Sharing is caring! QA feedback  User A edits profile page; has details of user B  Could not reproduce the issue Assumption  “This is a proxy/load balancing issue” Analysis  Security issues in the session management Conclusions  Each team might have their own ideas about the issue  Further investigation is required if opinion differs on the same matter 16
  17. 17. Login Fails Open QA Feedback  “When I login using these steps, the Welcome page is blank” Analysis  Login bypass via internal pages Conclusion  A defect affecting a critical security component (e.g. authentication) is a vulnerability 17
  18. 18. Lethal Injections QA Feedback  Last name with single quote (e.g. N’Doba) accepted  Database error when changing last name from user profile page Analysis  The single quote broke the SQL query statement  SQL injection allowed remote code execution Conclusion  Simple observations can make the difference 18
  19. 19. I like refunds… QA Feedback  Refund action is possible  For each refund, 50 cents is given to merchant  System accepted 2 split refund transactions for the same payment Analysis  A 10 dollar payment refunded with mini transactions of 1 cent  For each mini transaction, 50 cents were given to the merchant  Fraud was possible Conclusion  A defect can lead to discovery of security issues in other components associated to the defect 19
  20. 20. I would like all the seats, please. QA Feedback  “System is fine but we did not test the release mechanism for booked seats” Analysis  System failed to free booked seats if not purchased Conclusion  Untested/out-of-scope area can lead to discovery of issues with security implications 20
  21. 21. Part IIIWhat can we do to improve things? 21
  22. 22. Some ideas Security testing is not part of QA.  Is it someone’s fault? Would like access to:  Bug tracking software  Access to identified defects (database) Spot weaknesses by area (e.g. authentication)  Gives an indication where to look first or with more focus Pre-testing meeting with QA team  See what they think about the application 22
  23. 23. Security and QA Provide security test cases  Preliminary security testing  No exploitation – flag potential issues  Manual testing and white box approach Identify defects with security impacts earlier  Worst case: QA needs to be re-performed after a major re-design Costs vs ROI  Costs increase for additional testing during QA  ROI achieved if no delays or unexpected costs arise 23
  24. 24. Example of preliminary checks Case-sensitive login  Username:  Test  test Authorisation controls  Profile.aspx?memberId=10000  Try: memberId=10001  If user 10000 can access user 10001’s page without authorisation 24
  25. 25. Further examples Strong password format  User can choose “password” as password  User can choose “qwerty” as password Credentials enumeration  Error message returns “wrong username”  Error message returns “wrong password” Malformed request  Debug exception output is publicly viewable 25
  26. 26. Quick checks Cookie settings  No Secure flag in HTTPS  No HTTPOnly flag  Sensitive info in cookie  Cookie domain and path incorrectly set Data Transport  Sensitive information transmitted over HTTP Data Storage  Credentials stored in database with no hash 26
  27. 27. Collaboration Online collaboration  OWASP Project to bridge gap between security and QA  QA communities should do the same Local collaboration  Increase collaboration between chapters  OWASP NZ chapter  ANZTB SIGIST  Security talks at QA chapter meetings and vice versa 27
  28. 28. Conclusion Wrap up  QA is prerequisite for any security testing  QA defect database should be accessed by security staff  Preliminary security test-cases can identify low-hanging fruit 28
  29. 29. Questions? Thanks! E-mail: roberto.suggi@security-assessment.com Blog: http://malerisch.net Twitter: https://twitter.com/malerisch 29
  30. 30. References/Useful Links Software Security Testing in Quality Assurance and Development  http://www.qasec.com/ Fuzzing for Software Security Testing and Quality Assurance  ISBN-10: 1596932147, Artech House; 1 edition (June 30, 2008) OWASP – Software Quality Assurance  https://www.owasp.org/index.php/Software_Quality_Assurance Vulnerability as a Function of Software Quality  https://www.giac.org/paper/gsec/647/vulnerability-function-software- quality/101493 Why QA Doesnt Do Security Testing  https://www.infosecisland.com/blogview/10736-Why-QA-Doesnt-Do- Security-Testing.html 30
  31. 31. References/Useful links Security is the sexy part of QA  http://www.madirish.net/justin/security-sexy-part-qa Are Security and Quality Assurance Part of Your Software Development Life Cycle?  http://www.educause.edu/ir/library/powerpoint/WRC0667.pps 31

×