![Negative Use Cases (examples)
• Web-Based Applications – SQL Injection Strings
– xxx’; SELECT * FROM USERS;--
– yyy’ SELECT * FROM USER; --
– 9; SELECT * FROM USERS;-- COMMENT
– ASC; SELECT * FROM USERS
– UNION SELECT ALL 1--
– ; IF (LEN(USER)=1) WAITFOR DELAY '00:00:10‘--
– 1 and (char(65)%2Bchar(65)%2Bchar(65)%2B(select
name from [master]..[sysdatabases] where
dbid=1))>0](https://image.slidesharecdn.com/t23-150727151817-lva1-app6891/85/Improve-Security-through-Continuous-Testing-31-320.jpg)
Improve Security through Continuous Testing
- 1. Ensuring Security through Continuous Testing Jeremy Faircloth
- 2. Who am I? • Security Guy • Enterprise Applications Admin/Architect • Development/Operations Manager • Author – 16 Published Titles
- 3. What’s this about? • Uh… Ensuring security through continuous testing? • Let’s break that down…
- 4. Background • What are “vulnerabilities”? – Vulnerabilities are software bugs that allow the software to behave in an unexpected manner. • So what? – Vulnerabilities lead to “exploits”, the malicious usage of a vulnerability to disrupt or misuse the software. • One of the functions of “IT Security” is the prevention of this malicious activity. – This can be through inclusion in the SDLC or through controls that exist external to the SDLC.
- 5. You’re losing me… • What does a vulnerability look like and how is it exploited?
- 8. I’m lazy.
- 10. Security = Important… Got it! Whose job is it? The security guys!!! The developers!!!
- 11. What are developers doing today? • The developers are trained on security (a little) and are told to use “secure development patterns”. • Does this work? – Security is NOT a developer priority – features are. – Developer skill and knowledge varies – and security is very specialized. – Development means “figuring out how to make it work”. When it’s working then security elements are typically added.
- 12. What are security guys doing today? • While the development is happening, sometimes “static code analysis” is done. – But few developers understand the results. • When development and testing are complete, the application is scanned with “dynamic analysis” and “penetration testing”. • Security-related bugs are found and quickly patched by development just before the application goes to Production. – Usually by developers who have already moved on to building the next feature.
- 13. This works! • Well defined secure coding patterns help ensure secure code. • Scanning and remediating issues helps harden the application. • Having individuals trained in security performing development and interpreting scan results means more secure code.
- 14. …until it doesn’t. • Good developers with strong security knowledge have a high turnover rate. • Future application updates tend to introduce new vulnerabilities… and aren’t always subject to full security scanning. – SDLCs move FAST now! • Security bugs are usually classified as less important than bugs in functionality.
- 15. What about all that “security stuff”? • Security is changing… – The “perimeter” is gone. – The world is moving faster. – The attackers are getting better. • “With more attacks, more applications, less control, and less time to work, I can’t keep up.” – A Security Guy
- 17. Why just the security guys? • Many tools used by the security guys can be used by anyone as long as they can interpret the results. • This is no different from other forms of application testing; it’s just different use cases. • Tools + knowledge = Better testing results!
- 18. Three steps to paradise! • Teach security to testers and provide tools.1 • Develop security-related use cases and test.2 • Record the defects correctly.3
- 19. Teach testers security and provide tools. • Tools are important, but interpreting results is even more important. – Many false positives …and assumed false positives – Code vs. infrastructure – False negatives ?!?
- 20. Develop security-related use cases and test. • Negative/misuse cases: – A misuse case is the negative form of a use case. – A use case is a countermeasure to a misuse case. • Examples!!! – Single quote – Field size – Unexpected input
- 21. A better example Requirement: The field shall accept numbers between 1 and 600 Positive Use Cases: – Enter 1 – Enter 600 – Enter 10 numbers between 1 and 600 Negative Use Cases: – Enter -1 – Enter 0 – Enter 601 – Enter A – Enter 1.1 – Enter @#$ – Enter ¿ – Enter nothing (blank) – Enter ‘ – Enter <script>alert();</script>1
- 22. Record the defects correctly • Security bugs should be HIGH priority (Sev 1) • Developers need bugs presented in a way they understand – Bad Bug: Field XYZ is vulnerable to SQL injection – Good Bug: Field XYZ is accepting input outside of the required format/length causing a critical error • Sending bugs like this back to developers forces them to create more secure code
- 23. Why testers are our heroes • Security guys know security, but not the application. – Testers can test for vulnerabilities in process flows. – Testers know the application better than anyone… and know how to break it. – Tools only get you so far… • Testers have “early access” to the application – The earlier a vulnerability is caught, the better the fix will be. • If testers can test for common vulnerabilities, security guys can focus on the less common or more complex.
- 24. What’s this about? • Ensuring security through continuous testing. – Ensuring security: • Identifying vulnerabilities • Recording security defects correctly • Forcing development of secure code – through continuous testing. • Creating negative use cases • Testing for common vulnerabilities • Including security testing earlier in the SDLC • Testing security use cases constantly
- 25. How do we do this? • If you’re a tester… – Learn more about security! • Attend security courses • Learn how to hack! • Try to break things – Encourage your security guys to work with you. • Some security guys don’t like to share… sorry. • Most do! Learn from them! – Work with your management to change how testing is done. • Include negative use cases • Include use cases that focus on security
- 26. How do we do this? • If you lead a testing team… – Learn more about security! • Attend security courses • Learn how to hack! • Try to break things – Encourage your security guys to work with your team • Forge partnerships between security and testing • Include security guys in conversations about testing processes – Change how testing is done • Train your testers on security • Help them to understand negative use cases from the security perspective • Support them in including security testing
- 27. Summary • Vulnerabilities = Bad • Testing = Good • Testing for Vulnerabilities = Very Good • Secure Applications = GREAT!
- 28. Questions?
- 29. THANK YOU!
- 30. Negative Use Cases (examples) • Web-Based Applications – Send request/responses out of order – Modify contents of fields in queries – Modify POST data or cookie values – Send invalid or malformed values – Change source information (HTTP referrer, MAC address, IP address, username, etc.) in responses – Change parts of the URL that might be “useful” (ID fields, etc.) – Change XML responses – Modify web service calls
- 31. Negative Use Cases (examples) • Web-Based Applications – SQL Injection Strings – xxx’; SELECT * FROM USERS;-- – yyy’ SELECT * FROM USER; -- – 9; SELECT * FROM USERS;-- COMMENT – ASC; SELECT * FROM USERS – UNION SELECT ALL 1-- – ; IF (LEN(USER)=1) WAITFOR DELAY '00:00:10‘-- – 1 and (char(65)%2Bchar(65)%2Bchar(65)%2B(select name from [master]..[sysdatabases] where dbid=1))>0
- 32. Negative Use Cases (examples) • Web-Based Applications – XSS Strings – <SCRIPT>alert()</SCRIPT> – “><SCRIPT>alert()</SCRIPT> – ‘><SCRIPT>alert()</SCRIPT> – </SCRIPT><SCRIPT>alert()</SCRIPT> – javascript:alert() – vbscript:MsgBox() – “ style “font-family:expression(alert())”x=“ – +ADw-SCRIPT+AD4-alert();+ADw-/SCRIPT+AD4-