Assessing the security posture of a web application is a common project for a penetration tester and a good skill for developers to know. In this talk, We’ll go over the different stages of a web application pen test, from start to finish. We’ll start with tools used during the discovery phase to utilize OSINT sources such as search engines, sub-domain brute-forcing and other methods to help you get a good idea of targets “footprint”, automated scanners and their use, all the way to manual testing and tools used for fuzzing parameters to find potential SQL injection vulnerabilities. We’ll also discuss pro-tips and tricks that we use while conducting a full application penetration assessment. After this talk, you should have a good understanding of what is needed as well as where to start on your journey to hacking web apps.

1. Hacking Web Apps
Brent White

2. Hacking Web Apps
Sr. Security Consultant
at Solutionary
Twitter:
@brentwdesign
Brent White
-----------------------------------
www.solutionary.com

3. Disclosure Statement
(Dis – closure?)
The content within this presentation
represents the opinions and thoughts of the
presenter(s) and in no way represent the
thoughts or opinions of Solutionary, NTT,
NTT Com Security, or any of NTT’s
subsidiaries.

4. === INTRO ===
• High-level, from start to finish
of what we do during assessments
• We’re telling you how to get
started & pro-tips to save you
time and heartache
• Using this info doesn’t make you
a “Hacker”. (l33t h4x0r)
• You have to dig in, learn &
practice.
• It takes time!

5. === Kick Off ===
A few things must happen before
the assessment starts:
• Kick-off call
• Rules of engagement doc
– When
– Limits
– Scope
– Point of contacts

6. === Evidence Gathering ===
A report is expected at
the end of the
assessment.
• The more evidence you
collect, the easier
this makes your life.

7. === Evidence Gathering ===
KeepNote is a great choice.
– Available for Linux, Windows and Mac.
– Paste screenshots, Create embedded pages
and folders.
Group things based on vulnerability:
– Folder named "Default Server Pages" and
each page will be the host & port.
– Color-code the folder based on risk-rating.
(personal preference)
– Easy exporting of the KeepNote notebook
as .html files & easy copy/paste into your
program of choice while report writing.
– Dradis is another popular choice in Kali.

8. === Evidence Gathering ===
By Host: By Vuln

9. === Evidence Gathering ===
Document:
– HTTP Request and Response for each
vulnerability
– Any unscheduled downtime or issues
– Changes in test data
• Creation of additional accounts, change
passwords, or client-provided data
• Intentional or inadvertent modification
of any static data resource
– (i.e. Added or altered files)

10. === Evidence Gathering ===
Do not share screenshots or data
of a great "hack” online.

11. === Evidence Gathering ===
Get relevant, legible screenshots
of the vulnerability.
Good evidence.
Bad screenshot!

12. === Evidence Gathering ===
Get relevant, legible screenshots
of the vulnerability.

13. === Evidence Gathering ===
• Call out the specific issue during the write-up,
so the client can see exactly what was sent.
– If a screenshot, outline the vulnerability.
– If text, highlight the vulnerability.

14. === Evidence Gathering ===
List all known
affected
pages and
parameters for a
vulnerability.

15. === Evidence Gathering ===
• Have a methodology and
checklist to go by during
each assessment.
– OWASP has a good methodology
and checklist.
– Helps to keep you
on track
- Don’t limit yourself
to it!

16. === Discovery / OSINT ===
• Search engines, Pastebin,
ShodanHQ, Recon-NG, PwnedList.com,
for anything related to the
application.
– This is a manual and time-consuming
process, but not one to be ignored!
– Email archives, logins, dev help
forums
– Any leaked credentials, known
previous hacks?
– Sites like urlvoid.com to check for
known active malware/threats for the
domain

17. === Discovery / OSINT ===
Found info on DB type, schemas & test
credentials through old development
help forums that were STILL valid!

18. === Discovery / OSINT ===

19. === Discovery / OSINT ===

20. === Automated Scanning ===
"Why do you run
automated
tools?
You're supposed
to be a
hacker."

21. === Automated Scanning ===
• HUGE time-saver with
assessments!
– Wide range of tests, quickly
– Finds “low-hanging fruit”
A vuln scan is
NOT
a penetration
assessment!

22. === Automated Scanning ===
...and to those who say it is:

23. === Automated Scanning ===
• Nessus
– Looks at the host and web app.
Covers everything from SSL/TLS
layer, content discovery, basic
CGI vulns and more.
• IBM App Scan
– More web app focused for things
such as SQL/LDAP injections, CSRF
and XSS, inspect WSDLs, etc...

24. === Automated Scanning ===
• BurpSuite Pro
– Built-in "Active" scanner, content
spider and content discovery brute-
forcer tools.
• Nikto
– Great for finding default pages,
known vulnerable scripts, CGI
testing and more
– Also built in to Nessus, but can add
a great deal of time to the scan
– We prefer to use this separately,
outside of Nessus. It gives me more
control.

25. === Automated Scanning ===
– Identifies known WP vulnerabilities
– Enumerates themes, plug-ins and usernames
– Also other content-management system
scanners out there for Joomla, Drupal and
more.

26. === Automated Scanning ===

27. === Automated Scanning ===
• PRO TIPS:
– You want to verify the settings of
the automated scanner. Don't just
blindly click "scan" after entering
a URL.
– Make sure that you're not using
something that's checking for
Denial-of-Service (DoS) unless
specifically requested by the
client.
– Number of threads/connections at a
time? Don't flood the host.

28. === Automated Scanning ===
• PRO TIPS:
– Add any pages/functions the client
has asked you to avoid. (Password
reset page, sign-up page, "Contact"
forms)
– Might need to specify a "Page not
found" or Error 404 page to help
weed out false-positives for file
discovery.
– Configure the log-in process and
credentials for authenticated scans.
– You must take the time to verify the
results and remove false-positives!!

29. === Automated Scanning ===
Then when you’re ready,
Gooooooooooooo!

30. === Manual Testing ===
Automated Scanner results:
– Document the vulnerabilities that
are legitimate.
• Can you take it further than the
scanner?
• For example, if the scanner suspects
SQL injection, see if you can exploit
and dumb the tables with SQLMap.

31. === Manual Testing ===
Explore the application through a
proxy program like BurpSuite Pro.
– Manually explore the app while the
"Spider" and "Content Discovery"
tools are running.
– Alternatives:
• OWASP Zap
• Paros

32. === Manual Testing ===
• Review the server response to
help verify what the server is
running (IIS, Apache)
• Parameter Fuzzing
– How do they handle characters and
commands outside of the normal
expected input/actions?
• Parameters can be directly in
the URL. They are also found in
HTTP POST requests

33. === Manual Testing ===
• Test for:
– Cross-site Scripting (XSS)
– Cross-site Request Forgery (CSRF)
– SQL/LDAP injection
– Local & Remote File Inclusion
(LFI/RFI)

34. === Manual Testing ===
• BurpSuite Pro has lists
available that you can load for
file discovery, XSS, SQLi,
usernames, directories & more.
– There are also several places to
download your own lists, or make
your own.
– XENOTIX by OWASP is a good
XSS scanner w/ big list.

35. === Manual Testing ===
Specify the parameters you want to
fuzz.

36. === Manual Testing ===
– Save the POST or GET request and
execute with SQLMap to search for
SQL injection.
– BurpSuite has a SQLMap plugin.

37. === Manual Testing ===
• Is sensitive info being passed
through the URL in a GET request?
– Usernames, Passwords, Session ID
• Look for valuable comments in the
source code of the HTTP Responses
– Internal IPs, DB names, usernames,
"hidden" admin URLs, database calls
in JavaScript and more!
– This is certainly a manual process
and is time-consuming. However, it
can pay off.

38. === Manual Testing ===
To prevent “death by PowerPoint”:

39. === Manual Testing ===
• Authentication - can it be
bypassed or broken?
– Can you access URLs/functions as an
unauth user that you could while
logged in?
– Can you re-use the session token
after logging off?
– Is there a "log off" feature?
– Can you have multiple sessions as
the same user at the same time?
– What are the password requirements?
– What’s the password change process?

40. === Manual Testing ===
• Look at the host, not just the
web app
– Identify the web server platform.
Apache, IIS?
• If it's an old/outdated install, look for
exploits
– Is there an admin portal available?
• cPanel, Apache Tomcat Manager, etc...
– Are the test/default creds valid?
– Search for backup, default &
obsolete files
– Is directory browsing enabled? What
about directory rights?

41. === Manual Testing ===
– Look for dangerous HTTP methods
• ie...PUT, COPY, DELETE, TRACE
– Are they vulnerable to directory
traversal, Shellshock, Heartbleed?
– Use Nmap to see what ports/
services are open to the public.
• Are other things open other than 80 &
443?

42. === Manual Testing ===
– Look at SSL/TLS settings for known
and weak cipher vulns, expired or
untrusted certificates
• SSLScan in Kali or Qualys SSL Labs is
a good online resource too
– SSL Enforcement
• Can you access HTTPS areas by HTTP?

43. === Manual Testing ===
Look for file uploading features.
– Can you upload malicious shell scripts?
• PHP, ASP, ASPX, .WAR, shell scripts

44. === Manual Testing ===
Evasion against AV, IDS, IPS, WAFs
• Obfuscation, Polymorphic
• File Extensions
• File Wrapping

45. === Manual Testing ===
• Continue to study & understand
each attack vector.
– Know what is going on behind the
scenes after you push a button.
– Several great books and free
resources online! (Save $$)
• Practice in a lab, NOT on a
client’s site. ☺
• Then....

46. Go hack some websites!

47. Hacking Web Apps
Sr. Security Consultant
at Solutionary
Twitter:
@brentwdesign
Brent White
-----------------------------------
www.solutionary.com