2. A Quick Vocab.
▪ Vulnerability: A flaw or weakness in system security procedures, design,
implementation, or internal controls that may result in a security breach or a
violation of the system's security policy.
▪ Threat: The potential for a specific vulnerability to be exercised either intentionally
or accidentally
▪ Control: measures taken to prevent, detect, minimize, or eliminate risk to protect
the Integrity, Confidentiality, and Availability of information.
▪ Vulnerability Assessment: The process of identifying, quantifying, and prioritizing
(or ranking) the vulnerabilities in a system.
3. What is Information Security?
▪ Information Security means protecting information and information systems from
unauthorized access, use, disclosure, disruption, modification or destruction.
▪ Term Information Security follows CIA
4. • Confidentiality: Assurance that the information is accessible only to
those authorized to have access. Confidentiality breaches may occur
due to improper data handling or a hacking attempt.
• Integrity: The data or resources in term of preventing improper and
unauthorized changes. Assurance that Information can be relied upon to
be sufficiently accurate for its purpose.
• Availability: Assurance that the systems responsible for delivering,
storing and processing Information are accessible when required by the
authorized users
CIA Explained:
5. Vulnerabilities
Where do they come from?
1. Flaws in software
2. Faulty configuration
3. Weak passwords
4. Human error
I. Inappropriately assigned permission levels
II. System inappropriately placed in infrastructure/environment
Vulnerabilities don’t go away by themselves
6. 4.2 Information Gathering
1. Google Hacking Database
2. Internet Archive : WAYBACK MACHINE
3. Robots.txt
4. Fingerprint Webserver & Application (X-Powered-By, Server headers)
5. Crawl the Web Application
6. Review Comments and metadata.
7. Review & understand Entry points in the application
7. 4.3 Configuration and Deployment Management
Testing
1. Test for default credentials
2. Test for Generic/Default Error Pages (404, 500, 203 etc.)
3. Direct referencing of Sensitive Documents without proper Authentication.
4. Check for broken Links
5. Test for HTTP Methods (PUT, DELETE, TRACE, OPTIONS, CONNECT)
6. Check for HTTP Strict Transport Security (HSTS)
7. Test for access of Admin Interfaces by privilege escalation/bypass.
8. Test for Rich Internet Applications (RIA) that have adopted Adobe's
crossdomain.xml policy.
8. 4.4 Identity Management Testing
1. Test Role Definitions.
2. Test User Registration & Provisioning Process.
3. Test for Account Enumeration and Guessable User Account
4. Test for Weak or unenforced username policy
9. 4.5 Authentication Testing
1. Test for Sensitive Information being sent over HTTP
2. Check for AUTOCOMPLETE & CAPTCHA.
3. Test Account Lockout Threshold.
4. Check for Weak Password and Security Q/A Policy.
5. Test for Password Change/Reset Policy.
6. Test for weaker authentication through alternative channel.
7. Check for Default credentials.
11. 4.8 Input Validation Testing
1. XSS, SQL Injection, Buffer Overflow
2. Local / Remote File Inclusion
3. Command & Code Injection
4.9 Testing for Error Handling
1. Enumerate Server Error Pages & Information Disclosed on same
12. 4.10 Testing for weak Cryptography
1. Perform SSL Scan
2. Verify for Secure Certificate signing algorithm
3. Verify for CA
4. Verify SSL / TLS Version supported
5. Verify for Weak Cipher Suites Supported
6. Check for vulnerability of POODLE, FREAK, CRIME, BEAST Attacks.
7. Check the Validity / Expiry of the Certificate.
13. 4.12 Client Side Testing
1. DOM based XSS
2. Un-validated URL Redirect
3. X Origin Resource Sharing
4. Clickjacking / UI Readdressing
5. Local / Cache storage
4.11 Business Logic Testing
14. One size doesn’t fit all!
Customize your plans & procedures
Differently for different types of
Application.
Do not generalize the Risk Rating.
15. Things to Remember
1. Stick to your protocols
2. Take the Application Version No. & Compilation/Build Time-stamp with
evidence(screenshot) as the VAPT done & Report prepared by you is valid
only on the same application until-unless tampered.
3. Make the client aware of the risks involved while performing the Security
Audit.
4. Inform the client pre & post VAPT Activity.
5. Take PoCs wherever possible.
6. Filter your results from False-Positives.
7. Stick to the Report Format (improve it with your manager’s permission)