Using Free Tools To Test Web Application Security
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Using Free Tools To Test Web Application Security
• Matt Neely, CISSP, CTGA, GCIH, and GCWN – Manager of the Profiling Team at SecureState – Areas of expertise: wireless, penetration testing,
physical security, security convergence, and incident response
– Over 10 years of security experience • Outside of work:
– Co-host of the Security Justice podcast
Speaker Biography
SecureState Overview A Management Consulting Firm Specializing in Information Security
• Founded in September 2001 • Payment Card Industry (PCI) Certified • Qualified Security Assessor (QSA) • Approved Scanning Vendor (ASV) • Qualified Payment Application
Security Company • Largest dedicated security company
in the Great Lakes Region • Number of Employees: 47
3
The Company We Keep The Company We Keep Key Industries: Retail, Financial Services, Healthcare, Critical Infrastructure, Professional Services, Service Providers, Education, Food Service, Entertainment, and Government
SecureState Overview Audit and Compliance
• PCI (Payment Card Industry) • ISO 27001/SAS 70 • SOX, GLBA, HIPAA, TG-3, NERC/CIP etc. • INFOSEC (Information System Security Risk Assessment)
Profiling and Attack • Web Application Security (WAS) • Attack and Penetration Services (internal, external, client, physical, wireless) • Wireless Audits • Training
Risk Management • Security Program Manager (SPM) • StateScan • SecureTime • Architecture Reviews
Business Preservation Services • Data Forensics/Incident Response • Business Impact Analysis
Advisory Services • CISO Advisement • Risk Management • Special Projects
• Insecure web applications are the most common way attackers penetrate companies from the Internet and gain access to sensitive information
• As companies harden their perimeter attackers are moving to attacking web applications
• Vulnerabilities in web applications are the fastest growing type of vulnerability
Importance of Assessing Web Applications
• Two options to meeting requirement 6.6 • Option 1: Verify that public-facing web applications are
reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows: – At least annually – After any changes – By an organization that specializes in application security
• Assessments may be performed by a qualified internal resource or a qualified third party
– So all vulnerabilities are corrected – So the application is re-evaluated after the corrections
• Option 2: Verify that a web-application firewall is in place in front of public-facing web applications to detect and prevent web-based attacks.
PCI DSS 1.2 Requirement 6.6 Compliance
• Black Box – Scanning a site with an automated tool – Automated tools are prone to false positives and will not find flaws in
business logic • Grey Box
– Manually testing a site for vulnerability • 80% manual • 20% automated
– Assessor should review use case documentation to understand the business logic of the site and tailor attacks to the specific site
– Quality of the test relies on the experience of the tester • White Box
– Source code review – Very thorough – Very resource intensive
Web Application Security Assessments
Where Assessments Fit in SDLC
A1 – Injection A2 – Cross-Site Scripting (XSS) A3 – Broken Authentication and Session Management A4 – Insecure Direct Object References A5 – Cross-Site Request Forgery (CSRF) A6 – Security Misconfiguration A7 – Insecure Cryptographic Storage A8 – Failure to Restrict URL Access A9 – Insufficient Transport Layer Protection A10 – Unvalidated Redirects and Forwards
OWASP Top 10 - 2010
• Grendel Scan • Nikto • Paros • Skipfish • W3AF
Free Web Vulnerability Scanners
• Acunetix • Burp-Pro • Cenzic Hailstorm • HP WebInspect • IBM Rational AppScan
Commercial Web Vulnerability Scanners
• Burp • Paros • WebScarab
Web Proxies
• Newest versions of Firefox and IE implement client side controls to block certain attacks such as cross-site scripting
• Complicates testing and leads to validation problems • Disable controls if possible or test with an older
browser • Do not use older browsers or browser with
security features disabled for general web surfing
Warning: Testing with the Newest Versions of IE and Firefox
• Set up the scanner • Crawl and spider the site • Run scan • Validate results
Web Application Scanning Process
Lab Setup
• Connect to the wireless network – SSID: SecureState – Password: gobrowns
Connecting to the Network
• Browse to: http://192.168.1.102/paros/ • Download the version of Paros for your OS • Run installer
Install Paros
• Tools Options Local Proxy – Note address and port
• Note: Default may need to be changed in using multiple proxies
Setting Up Paros as a Proxy: Determine Proxy Port Used by Paros
Setting Up Paros as a Proxy: Configure IE to Use a Proxy Step 1
Setting Up Paros as a Proxy: Configure IE to Use a Proxy Step 2
Setting Up Paros as a Proxy: Configure IE to Use a Proxy Step 3
Setting Up Paros as a Proxy: Configure Firefox to Use a Proxy Step 1
Setting Up Paros as a Proxy: Configure Firefox to Use a Proxy Step 2
Setting Up Paros as a Proxy: Configure Firefox to Use a Proxy Step 3
Tour of Paros
Intercepting and Manipulating Data
• Spidering is an automated process in which Paros follows links on a page to generate a site map – By default Paros ignores links to external sites
• Paros uses the site map to determine which pages will be tested
• Very important to also manually crawl the site to ensure every page is mapped and scanned – Automated spiders often miss links in JavaScript
Spidering and Crawling a Site
Using Paros to Spider and Crawl
Scanning for Vulnerabilities
Reviewing the Results
• Even the best scanner will produce false positives • Very important to manually validate all scan results
Validating the Results
• Cross-Site Scripting (XSS) – Occurs when attacker sends malicious link, code, email to
victim – Allows for execution of JavaScript in victim’s browser context – Allows for cross-site communications
• Cause – No input validation of headers, cookies, query strings, form
fields (visible or hidden) • Possible Outcomes
– Session Hijacking – Site Defacement – Phishing through URL redirection – Worms
A2 - Cross-Site Scripting (XSS)
• SwitchProxy • NoScript • Firebug • Hackbar • SQL Inject ME • XSS ME • User Agent Switcher • Web Developer Toolbar
Useful Firefox Extensions
• DirBuster • JBroFuzz • SwfScan
Other Useful Tools
• Web Hackers Handbook • OWASP:
– Numerous free projects, programs, and educational resources
– OWASP Podcast – http://www.owasp.org
• Practice web applications: – OWASP Broken Web Applications Project – Collection of practice web applications in a single
virtual machine – http://code.google.com/p/owaspbwa/
Where to Learn More
• Injection Flaws – SQL Injection is the most common injection flaw – Occurs when user-supplied data is sent to interpreter as part of a
command or query – Attacker tricks interpreter into executing unintended commands
via specially crafted input • Cause
– User input is not properly sanitized • Possible Outcomes
– Create, Read, Update, and/or Delete Data – Command Execution – Full Host Compromise
A1 – Injection Flaws
Related Documents
