Upload
marian-marinov
View
23
Download
0
Embed Size (px)
Citation preview
How PENETRATION TESTING techniques CAN HELP YOU IMPROVE
your QA skills
Marian HackMan Marinov<[email protected]>
Who am I? Who am I?
❖ Chief System Architect of Siteground.com
❖ Sysadmin since 1996
❖ Organizer of OpenFest, BG Perl Workshops,
LUG-BG and similar :)
❖ Teaching Network Security and Linux System
Administration at Sofia University
☹☹☹☹☹☹The QA position is underrated and heavily
undermined by the web industry
I really admire the work that QA people do!
Let's clear some stuff Let's clear some stuff
❖ Black box testing
❖ Gray box testing
❖ White box testing
Pentesting what? Pentesting what?
❖ Pentesting is actually QA testing :)
❖ The plans that pentesters prepare for attacks are similar to the plans QA devise to test the same software.
❖ The difference is the way the testing is performed and what is evaluated for testing.
The fist part of the presentation would be about Black/Grey box testing
The fist part of the presentation would be about Black/Grey box testing
Simply because it shows some very important differences
Simply because it shows some very important differences
Pentesters start by gathering informationabout the infrastructure and the softwarePentesters start by gathering informationabout the infrastructure and the software
QA guys, usually relay on Devs, Documentation and
Requirements for the same info
QA guys, usually relay on Devs, Documentation and
Requirements for the same info
Pentesters define the expected successfulresult by running one real life test and
writing down its result. Than every other response is considered failure
Pentesters define the expected successfulresult by running one real life test and
writing down its result. Than every other response is considered failure
Every time a QA see an error in the logs of the app or the server, she is considering it, a failure
Every time a QA see an error in the logs of the app or the server, she is considering it, a failure
Pentesters try to find the places that are most likely to be vulnerable (common flaws and bugs)
Pentesters try to find the places that are most likely to be vulnerable (common flaws and bugs)
QAs tryies to test the whole applicationQAs tryies to test the whole application
Pentesters always look for chain of events, that if triggered, will give them access
(Design vulnerabilities)
Pentesters always look for chain of events, that if triggered, will give them access
(Design vulnerabilities)
QAs usually focus on the current layerof the application and relay on the tests
of the next level to cover the whole
QAs usually focus on the current layerof the application and relay on the tests
of the next level to cover the whole
Pentesters try to use and abuse unspecified behavior in functions, and for that they try generate all impossible inputs
Pentesters try to use and abuse unspecified behavior in functions, and for that they try generate all impossible inputs
QAs usually limit their tests to a predefined set of inputs or
limited number of generated inputs
QAs usually limit their tests to a predefined set of inputs or
limited number of generated inputs
Every time a test fails, pentesters expand the search
Every time a test fails, pentesters expand the search
With QAs, every time a test fails,they return the code to the Dev team
With QAs, every time a test fails,they return the code to the Dev team
Pentesters have more time and they are working on the LIVE environmentPentesters have more time and they are working on the LIVE environment
QAs do their tests on mockup/staging environments
QAs do their tests on mockup/staging environments
Pentesters use tools for generating wordlist and dictionaries
Pentesters use tools for generating wordlist and dictionaries
QAs should start doing the same...QAs should start doing the same...
Sometimes pentesters get their hands onbinaries and they do try to reverse them,
to understand and break them
Sometimes pentesters get their hands onbinaries and they do try to reverse them,
to understand and break them
I'm yet to see a QA do some reversing...I'm yet to see a QA do some reversing...
❖ ❖ Decision table testingDecision table testing
❖ ❖ All-pairs testingAll-pairs testing
❖ ❖ Equivalence partitioningEquivalence partitioning
❖ ❖ Boundary value analysisBoundary value analysis
❖ ❖ Cause–effect graphCause–effect graph
❖ ❖ Error guessingError guessing
❖ ❖ State transition testingState transition testing
❖ ❖ Use case testingUse case testing
❖ ❖ User story testingUser story testing
❖ ❖ Domain analysisDomain analysis
❖ ❖ Combining techniqueCombining technique
Black/Gray box testingBlack/Gray box testing
Generally pentesters use more tools for a single test then QAs.
They try to combine more then one completely valid use case, to construct
one test, that will break the system.
Generally pentesters use more tools for a single test then QAs.
They try to combine more then one completely valid use case, to construct
one test, that will break the system.
And here is something from the book And here is something from the book Exploiting SoftwareExploiting Software::
An attacker starts with breaking the An attacker starts with breaking the rules and undermining assumptions. rules and undermining assumptions. One of the key assumptions to test is One of the key assumptions to test is the "implicit trust" assumption. the "implicit trust" assumption. Attackers will always break any rule Attackers will always break any rule relating to when, where, and what is relating to when, where, and what is "allowed""allowed"
Black/Gray box testingBlack/Gray box testing
If you want to broaden your test case horizons...
I advise you to read the specific techniques
outlined in "Exploiting Software"
If you want to broaden your test case horizons...
I advise you to read the specific techniques
outlined in "Exploiting Software"
❖ ❖ shell command injectionshell command injection
* argument injection* argument injection
* command delimiters* command delimiters
* multiple parsers and double escapes* multiple parsers and double escapes
❖ ❖ Plumbing pipes, ports and permissionsPlumbing pipes, ports and permissions
❖ ❖ Exploiting the filesystemExploiting the filesystem
* user-supplied variable passed to the filesystem calls* user-supplied variable passed to the filesystem calls
* postfix null terminator* postfix null terminator
* postfix null terminate and backslash* postfix null terminate and backslash
* relative path traversal* relative path traversal
❖ ❖ Manipulating environment variablesManipulating environment variables
❖ ❖ Leveraging poor session authenticationLeveraging poor session authentication
* Session ID, Resource ID and Blind trust* Session ID, Resource ID and Blind trust
* Bruteforcing session IDs* Bruteforcing session IDs
* Multiple paths of authentication* Multiple paths of authentication
* Failure to check error codes* Failure to check error codes
Specific techniques Specific techniques
❖ ❖ Every QA is doing exactly thisEvery QA is doing exactly this
❖ ❖ But let's look at the differencesBut let's look at the differences
White box testingWhite box testing
❖ ❖ Pentesters do whitebox testingPentesters do whitebox testing
* when they are testing opensource apps * when they are testing opensource apps
* if they were given the code* if they were given the code
❖ ❖ Pentesters usually try to find bugs in the Pentesters usually try to find bugs in the integration between the app they have the integration between the app they have the source to and the app which source they don't source to and the app which source they don't
❖ ❖ Pentesters check, does the software comply Pentesters check, does the software comply with with allall the security guidelines for the specific the security guidelines for the specific language or systemlanguage or system
White box testingWhite box testing
❖ ❖ Pentesters use debuggers Pentesters use debuggers
* to inject code* to inject code
* change memory * change memory
* even change the flow of the application* even change the flow of the application
❖ ❖ Injecting code or otherwise influencing the Injecting code or otherwise influencing the application is considered by many, not possible.application is considered by many, not possible.
* This is now a reality!* This is now a reality!
❖ ❖ Pentesters consider bug in one layer as an Pentesters consider bug in one layer as an open door for your whole appopen door for your whole app
White box testingWhite box testing
❖ ❖ Code coverageCode coverage
* Control flow testing* Control flow testing
* Data flow testing* Data flow testing
* Branch testing* Branch testing
* Statement coverage* Statement coverage
* Decision coverage* Decision coverage
* Modified condition/decision coverage* Modified condition/decision coverage
* Prime path testing* Prime path testing
* Path testing* Path testing
White box testingWhite box testing
QA
❖ ❖ Code static analysisCode static analysis
❖ ❖ Analysis ofAnalysis of
* memory states, finding possible entry * memory states, finding possible entry points for malicious codepoints for malicious code
* interaction between different parts of * interaction between different parts of the software(exchanging data between the software(exchanging data between APIs and Frameworks)APIs and Frameworks)
❖ ❖ Forcing race conditions, filling buffers Forcing race conditions, filling buffers and then examining the performance of and then examining the performance of the app and its memory structuresthe app and its memory structures
White box testingWhite box testing
QA
❖ ❖ In order to be able to build more In order to be able to build more extensive tests, you have to be aware of extensive tests, you have to be aware of the possible issues that may happen the possible issues that may happen with:with:
- your software- your software
- the language(s) that you are using- the language(s) that you are using
- the infrastructure that is hosting your - the infrastructure that is hosting your applicationsapplications
Finally!Finally!
Related booksRelated books Marian HackMan Marinov<[email protected]>