2. Definitions
1. Selenium - Selenium automates browsers like
Chrome/Firefox/IE.
1. Integration Testing - Testing a full user workflow in an
application
3. After this presentation, you can:
1. Make existing tests find security bugs
2. Without false positives
3. With minimal changes
4. After this presentation, you can:
1. Make existing tests find security bugs
2. Without false positives
3. With minimal changes
QAs! Managers!
Test security while testing functionality!
5. After this presentation, you can:
1. Make existing tests find security bugs
2. Without false positives
3. With minimal changes
Penetration Testers! Security Engineers!
Find more bugs! Keep them fixed!
6. “Give me a place to stand and I will move the Earth”
- Archimedes
7. “Give me a place to stand and I will HACK THE PLANET!”
- Me
8. About Me
I started as a tester at DocuSign
Wrote integration tests for the API and web
interface
Currently work on the application security
team
14. What Web Application Scanners Do
Interpret
Responses
Login Send Payloads Give Report
15. What Web Application Scanners Do Badly
Interpret
Responses
Login Send Payloads Give Report
Doesn't understand business
logic!
Manual triage and
reproduction
16. What Web Application Scanners Do Badly
Interpret
Responses
Login Send Payloads Give Report
Doesn't understand
business logic!
Never even signed!!!
Manual triage and
reproduction
17. What Regular Testers Already Do
Modify the test to
hit all the test
cases
Find an idealized
workflow
Create an
automated
test
Find a bug
Use the previous
test to check if the
bug is fixed
18. What We Can Learn From Them
Modify the test to
hit all the test
cases
Find an idealized
workflow
Create an
automated
test
Find a bug
Use the previous
test to check if the
bug is fixed
Test lots of
scenarios!
Easy to reproduce!Get an actual user
workflow!
19. What a test can be used for
Modify the test to
hit all the test
cases
Find an idealized
workflow
Create an
automated
test
Find a bug
Use the previous
test to check if the
bug is fixed
Make all your strings:
<script>alert(1)</script>
Then send it to tons
of scenarios!
Show a failure if the
XSS alerts!
Anyone can
reproduce my bug!
21. Workshop - Setup
• Please have ZAP Installed from
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
• Clone the repository from
https://github.com/distrustCaution/integrated-security-example
• Please install NodeJS v8.11.1
• If you are on Windows, you may need to add C:Program Filesnodejs
to your path.
• Run ‘npm install’
• Run ‘npm run integrationTest’
22. Workshop Part 1 – Survey the Test Code
• Go to test/integration_tests/test_ui.js and
test/integration_tests/test_api.js
• Mission – Learn how:
23. Workshop Part 1 – Survey the Test Code
• Go to test/integration_tests/test_ui.js and
test/integration_tests/test_api.js
• Mission – Learn how:
• The http client is set up
• The selenium web driver is set up
• How accounts are created
• How accounts authenticate
• How tests are run
• What the assertions are
24. Workshop Part 2 - ZAP and Passive Scan
• Go to the file: “test/workshop/find_passive_results.js”
• In that file, look for the browser setup script
• We’ll send it through ZAP’s proxy
• Then we’ll use ZAP’s reporter for basic output
• To run use: npm run workshopPassive
• For automating it, you can use the ZAP API
• A great article by one of the other speakers here (Omer Levi Hevroni) on how
to use custom rules: https://medium.com/@omerlh/how-to-scripting-owasp-
zap-with-javascript-1c1898b1e7e0
25. Look for cookies
Insecure cookies:
browser.driver.manage.all_cookies
Non-httpOnly cookies:
return document.cookie
30. Workshop Part 2 – Looking for external scripts
• Go to the file: “test/workshop/find_external_scripts.js”
• To run use: npm run workshopExternal
• In selenium, try to get the results from:
“return window.performance.getEntries()” (try it in your browser first)
• We’ll filter it down to see if we get an error
31. Find Web App Bugs
Send Payload Run Test Check Payload
32. Find XSS the easy way
1. Create a payload ● <script>alert(1234)</script>
33. Find XSS the easy way
Create a payload ● <script>console.error(1234)</script>
PROTIP:
Alert will break tests
34. Find XSS the easy way
Create a payload
Use it
● <script>console.error(1234)</script>
● userName = “<script>...
35. Find XSS the easy way
Create a payload
Use it
Read it
● <script>console.error(1234)</script>
● userName = “<script>...
● Read selenium logs
36. Find Angular injection the easy way
Create a payload
Use it
Read it
● {{1234*1234}}
● userName = “{{1234*1234}}”
● Search the DOM for 188821744
37. Find Angular injection the easy way
Create a payload
Use it
Read it
● {{1234*1234}}
● userName = “{{1234*1234}}”
● Search the DOM for 188821744
PROTIP:
Big numbers
rarely collide
38. Workshop Part 4 – XSS
• Go to the file: “test/workshop/find_xss.js”
• To run use: npm run workshopXSS
• Generate a basic XSS payload: <script>console.error(1234)</script>
• Use “driver.manage().logs().get(webdriver.logging.Type.BROWSER)” to
get the browser logs
• Verify that your payload exists in the logs
39. Workshop Part 5 – Angular Injection
• Go to the file: “test/workshop/find_angular.js”
• To run use: npm run workshopAngular
• Generate a basic Angular Payload: {{2+2}}
• Look for it in the DOM with “return document.body.innerHTML”
40. Normal way to find SQL injection
Create a payload
Send it
Interpret it
● ‘ UNION SELECT 1
● userName = ‘ UNION SELECT 1
● Error!
41. Normal way to find SQL injection
Create a payload
Send it
Interpret it
● ‘ UNION SELECT 1
● userName = ‘ UNION SELECT 1
● Error!
What if it is too
early?
42. Easy way to find SQL injection
Create a payload
Send it
Break the test!
● ‘ UNION SELECT 12345
● userName = ‘ UNION SELECT 12...
● FAILURE!!
43. Workshop Part 6 – SQL Injection
• Go to the file: “test/workshop/find_sqli.js”
• To run use: npm run workshopSQLi
• Create a simple payload that could ‘break sql’ that contains characters
such as ‘, ”, or –
• Use it in the API tests, and see the failures you get back
44. Find XXE in test
Create a payload
Send it
Monitor the file for
reads
● <!DOCTYPE data SYSTEM
“file:///c:/myfile.txt">...
● userName = <!DOCTYPE data...
● ls –lu (bash) or
(gci filename).lastaccesstime (powershell)
46. Finding Authorization Bugs in CRUD
1. Alice makes the resource
2. Alice modifies the resource
3. Alice shares the resource with Bob
4. Bob reads the resource
47. Finding Authorization Bugs in CRUD
1. Alice makes the resource
2. Alice Eve modifies the resource
3. Alice Eve shares the resource with Bob Eve
4. Bob Eve reads the resource
48. Finding Authorization Bugs in CRUD
1. Alice makes the resource
2. Alice Eve modifies the resource
3. Alice Eve shares the resource with Bob Eve
4. Bob Eve reads the resource
Preparation as
“Victim”
Authorization bypass
attempt as “Attacker”
49. Finding Authorization Bugs in CRUD
1. Alice makes the resource
2. Alice modifies the resource
3. Alice Eve shares the resource with Bob Eve
4. Bob Eve reads the resource
Preparation as
“Victim”
Authorization bypass
attempt as “Attacker”
50. Workshop Part 7 – Authorization
• Go to the file: “test/workshop/find_authz.js”
• To run use: npm run workshopAuthz
• See how to create an ‘Evil’ account
• Attempt to do the following by modifying the api test:
• Read someone else’s note
• Modify someone else’s note
• Share someone else’s note
51. Co-Worker:
“So… most of the time it finds nothing and
doesn’t tell you about it?”
Me:
“Exactly! I don’t want it to succeed, I want it
to try.”
52. “Give me a place to stand and I will move the Earth”
- Archimedes
53. ✓ Don’t break tests
✓ Tailor it to your company
✓ Testers can now look for security bugs
✓ Keep it maintanable
✓ Help fix bugs faster
54. Join the conversation #DevSecCon
Thank you!
For more information go to:
https://github.com/distrustCaution/integrated-security-example
My twitter:
@Hackimedes
Notas del editor
Title Slide.
Lay it all out. Make this fade in the three.
After this presentation:
1. You will be able to turn selenium tests into web security tests
2. You will be able to turn API tests into deep fuzzing tools
3. You will be able to use both of the above testing methods to look for subtle business logic bugs
QAs get to know how to use their tests for some real good CI plus repurpose them
QAs get to know how to use their tests for some real good CI plus repurpose them
DocuSign is a esignature platform. I was an SDET. I wrote web and api tests. I would help out the security team by creating regression tests for them occasionally. DocuSign has an amazing set of integration tests.
I went from the familiar to the confusing
I was scared of this new thing
I was scared of this new thing
I started my career as an sdet -> switched to application security. Since I knew how to use my only tool “integration tests”, I use it for all the things. This ended up being a really good idea. I proxy my stuff into Burp and magic happened. This project was codenamed “Fart”
By building off my familiar, this enabled me to get a foothold in my new career.
I started my career as an sdet -> switched to application security. Since I knew how to use my only tool “integration tests”, I use it for all the things. This ended up being a really good idea. I proxy my stuff into Burp and magic happened. This project was codenamed “Fart”
By building off my familiar, this enabled me to get a foothold in my new career.
Scanners just login. Vomit their payloads, and then do not go deep through the app.
Scanners give terrible nebulous reports, at most click on things. Don’t do business logic. Don’t actually save you a lot of time. BUZZ LIGHTYEAR!
Scanners give terrible nebulous reports, at most click on things. Don’t do business logic. Don’t actually save you a lot of time. BUZZ LIGHTYEAR!
Show that Penetration testers already have the “depth and breadth”
Show that Penetration testers already have the “depth and breadth”. It is easy to reproduce.
Show that it can reproduce, and find bugs programmatically. Replace with plan of attack!
We’re going to find best practice issues!
Cookies can be set in lots of ways, finding insecure ones deep in flows is weird. For insecure cookies
In docusign we do not allow external scripts to run on our site. While csp is a valid way to protect against this, it can be broken. Federal agencies have hit this problem and it is hard to detect. We can just see how it works. Especially on nightly runs. Tests can see this in the normal flow, and just report out.
Problem solved right???
Nope! Developer Bob wants his scripts and loads them dynamically
Bad developer Bob! You will be detected!!! Your scripts even if loaded mysteriously will still show up in the performance logs
The process always followed the same steps internally: 1. Create a payload with an easy marker to add to the test 2. Add it to a list for later 3. See if it appears somewhere 4. Throw an error
Testers hate it when you break tests, so use console log. An unexpected alert will often break their test. This will ruin adoption.
The process always followed the same steps internally: 1. Create a payload with an easy marker to add to the test 2. Add it to a list for later 3. See if it appears somewhere 4. Throw an error
The process always followed the same steps internally: 1. Create a payload with an easy marker to add to the test 2. Add it to a list for later 3. See if it appears somewhere 4. Throw an error. Show screenshot
Angular injection works the same way. Just use the different break out. Screenshot
Another protip, GUIDs have small numbers, use larger numbers and use multiplication. This also reduces the odds of colliding with actual in-app numbers.
For blind sql injection, you can’t read outputs. So you have to wait.
For blind sql injection, you can’t read outputs. So you have to wait.
For blind sql injection, you can’t read outputs. So you have to wait. But testers can just connect to the DB and see what happened on test environments!!! Limitation for this method is that you need to stack queries.
XXE is pretty straight forwad
In large APIs, you might have a TON of endpoints to go through, you can iterate and have testing on all of them. You can iterate over all the authorization scenarios in an API. Closed accounts, shared accounts, shared resources, etc.
In large APIs, you might have a TON of endpoints to go through, you can iterate and have testing on all of them. You can iterate over all the authorization scenarios in an API. Closed accounts, shared accounts, shared resources, etc.
In large APIs, you might have a TON of endpoints to go through, you can iterate and have testing on all of them. You can iterate over all the authorization scenarios in an API. Closed accounts, shared accounts, shared resources, etc.
In large APIs, you might have a TON of endpoints to go through, you can iterate and have testing on all of them. You can iterate over all the authorization scenarios in an API. Closed accounts, shared accounts, shared resources, etc.
You want to go into the spirit of this. You don’t have to implement it exactly. Find the bugs that you need to do, and avoid false positives.
This is a useful tool, it’s not always the tool for the job, but you should have it as a blue teamer. Don’t break tests . QA’s hate that, you should fail a lot on your machine first to interpret the results. Don’t create work for them. Breaking the DOM is just fine on your runs, but not on the nightly run. You also don’t want some crazy sql thing to overwrite stuff.
You should tailor it to your company, use the methodology of having security testing at the same time as functionality testing.