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?

OWASP A8




CSRF takes advantage the fact that most web apps allow attackers to predict all the details of a particular action. Because browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones. Detection of CSRF flaws is fairly easy via penetration testing or code analysis. Attackers can trick victims into performing any state changing operation the victim is authorized to perform, e.g., updating account details, making purchases, logout and even login.

Consider the business value of the affected data or application functions. Imagine not being sure if users intended to take these actions. To check whether an application is vulnerable, see if any links and forms lack an unpredictable CSRF token. Without such a token, attackers can forge malicious requests. An alternate defense is to require the user to prove they intended to submit the request, either through reauthentication, or some other proof they are a real user (e.g., a CAPTCHA).

OWASP A9

Virtually every application has these issues because most development teams don't focus on ensuring their components/libraries are up to date. In many cases, the developers don't even know all the components they are using, never mind their versions. Component dependencies make things even worse. The full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact could range from minimal to complete host takeover and data compromise. Consider what each vulnerability might mean for the business controlled by the affected application. It could be trivial or it could mean complete compromise.

OWASP A10



Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page. Detecting unchecked redirects is easy. Look for redirects where you can set the full URL.

  • Review the code for all uses of redirect or forward (called a transfer in .NET). For each use, identify if the target URL is included in any parameter values. If so, if the target URL isn't validated against a whitelist, you are vulnerable.
  • Also, spider the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such a URL. If so, change the URL target and observe whether the site redirects to the new target.
  • If code is unavailable, check all parameters to see if they look like part of a redirect or forward URL destination and test those that do.

Our Culture

Valency Networks is a very agile, friendly and fun loving atmosphere and yet we maintain a cutting edge technical vibrant work environment.