Web Security Testing
Related Links
Please see below a list of key vulnerabilities which must be tested while performing a website or webportal penetration testing.
Business logic flaws
SQL injection faults
Cross site scripting (CSS) vulnerabilities
Authentication vulnerabilities
Session ID flaws
Cookie manipulation and poisoning
Privilege escalation
Cross site request forgery (CSRF) risks
Code and content manipulation
Header manipulation
Web Security Testing OWASP Top 10 Ratings
OWASP A6
The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm usage is common, particularly weak password hashing techniques. Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale. External attackers have difficulty detecting server side flaws due to limited access and they are also usually hard to exploit.
The first thing you have to determine is which data is sensitive enough to require extra protection. For example, passwords, credit card numbers, health records, and personal information should be protected. For all such data:
- Is any of this data stored in clear text long term, including backups of this data?
- Is any of this data transmitted in clear text, internally or externally? Internet traffic is especially dangerous.
- Are any old / weak cryptographic algorithms used?
- Are weak crypto keys generated, or is proper key management or rotation missing?
- Are any browser security directives or headers missing when sensitive data is provided by / sent to the browser?
OWASP A7
Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget. Detecting such flaws is easy. The hardest part is identifying which pages (URLs) or functions exist to attack. Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. Consider the business value of the exposed functions and the data they process. Also consider the impact to your reputation if this vulnerability became public.
The best way to find out if an application has failed to properly restrict function level access is to verify every application function:
- Does the UI show navigation to unauthorized functions?
- Are server side authentication or authorization checks missing?
- Are server side checks done that solely rely on information provided by the attacker?
