Several vulnerabilities were covered in Injection Attacks, but there are even more that need to be covered. This is not an all-inclusive list, but one that you should be aware of.   

Other common flaws that might be found during a pentest are:

• Misconfigurations: Humans make errors and a human would be responsible for configuring the system. They could make an error in the configuration causing the application to reveal extra data or allow access to protected areas of the system. This is something that you might notice during testing. An example would be a samba share that also shares sensitive areas of the filesystem (think /etc). 

• Poor Input validation: The web app does have some input validation in place, but it could be improved for better input validation. 

• Insecure logon systems: When attempting to login to a web app the system could provide you with unintended information. For example, the system could provide details that it was a bad username and bad password. This tells you that a different username needs to be tried. You might also receive a message saying that a bad password was provided. This can tell you that the username is valid, but you just need to figure out the password. 

• Scripting errors: A common scripting error might be to allow anyone to upload data to the web app. A hacker could just upload massive amounts of files that fill the disk causing the application to crash. This is called Upload Bombing. Another type of attack, that can be handled with input validation, would be a Poison Null Byte Attack. This is where special characters are used for input and the script might not be able to handle the special characters and the attacker might be able to gain access. Another common scripting flaw is where web developers uses default scripts. These scripts are able to be viewed and you might be able to find a method to exploit it. When deploying their web app web developers might not remove the sample scripts that are part of the web app. These might also be able to be exploited.  Finally, programmers are not perfect and scripts that are used could be poorly written.

• Comments: Comments are an important part of coding. Any good developer will make sure to place meaningful comments within their code.  This is a method to provide documentation of what the code does and helps explain it to others who might work on the code later. Comments are provided to be useful, but an attacker can use this to also gain an understanding of how the code works! Comments could even reveal sensitive information about issues within the code that an attacker could take advantage of.  When you find a webserver running you should always check out the code!

• Lack of Code Signing: Code signing provides the ability to confirm that the code is authentic to end users. This is becoming more common and even your OS can detect if the code is authentic and from a known source.  When there is no code signing in place it could allow users to possible run code that has been manipulated by at attacker.  

• Error Handling Code: Developers must always anticipate any type of data entry.  Just because the web app asks for a number does not mean a user will always enter '50' they could enter the word fifty! How would the web app handle it? Would it crash or would it prompt the user to make sure to enter a number numerically? A lack of error handling could cause issues and expose the web app and code to various levels of risk. 

• Hard-Coded Credentials: This is when usernames and passwords are included in the source code. There are two types of hard-coded credentials. The first one is when the developer creates a hard-coded account in the code for maintenance purposes. If this username and password combination is made public anyone would be able to use it to access the app. The second type is when developers include a username and password combination that provides access to another system.  Think about PHP code that connects to a mysql database. A username and password combination would be required to access the database and run queries. Sometimes this code can get pushed to github or another source code repo. If this username and password combination is found the mysql database is compromised.

Stealing a Session ID: You can steal a Session ID in several ways. 

• Session Hijacking - An attack obtains a valid Session ID that belongs to another user. This can be done through XSS (cross-site scripting) or by exploiting a weakness in the session management infrastructure.  

• Session Prediction - The attacker tries to guess/predict the Session ID. This can be successful if the mechanism to generate the Session ID is predictable or is not random enough. 

• Session Sidejacking - The Session ID is captured due to be transmitted over an unsecured network (HTTP instead of HTTPS).

To mitigate session attacks, you should ensure HTTPS and session IDs are generated using a secure random number to avoid predictability,  session timeouts, multi-factor authentication, and IP Address verification. 

Stealing a Cookie: The same methods as stealing a Session ID can be used to steal a cookie. Keep in mind that if a user's cookie is stolen, the attacker can impersonate the user's session and gain unauthorized access to the user's account.