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
Session ID flaws
Cookie manipulation and poisoning
Cross site request forgery (CSRF) risks
Code and content manipulation
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:
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:
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).
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.
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.
Valency Networks is a very agile, friendly and fun loving atmosphere and yet we maintain a cutting edge technical vibrant work environment.