Skip to content

Commit

Permalink
Merge branch 'add-finding-descriptions' into 'main'
Browse files Browse the repository at this point in the history
Update finding descriptions

See merge request reportcreator/reportcreator!350
  • Loading branch information
aronmolnar committed Nov 24, 2023
2 parents f91cd0d + 6ae672f commit a2d87a8
Show file tree
Hide file tree
Showing 2 changed files with 13 additions and 0 deletions.
4 changes: 4 additions & 0 deletions docs/docs/d/web/sql-injection.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,3 +15,7 @@ Instead of a user's data with a specific user ID, the database returns data of a
Several variants of SQL injection vulnerabilities, attacks, and techniques occur in different situations depending on the database system used. However, they all share that the database interprets user input as SQL commands (as in the example above). Successful SQL injection attacks can have far-reaching consequences. One would be the loss of confidentiality and integrity of the stored data. Attackers could gain read and possibly write access to sensitive data in the database. SQL injection could also compromise the authentication and authorization of the web application, allowing attackers to bypass existing access controls. In some cases, SQL injection can also be used to execute operating system commands, allowing an attacker to gain complete control over the vulnerable server.

## Recommendation
* Use prepared statements or stored procedures wherever possible. Prepared statements are parameterized statements and prevent attackers from manipulating SQL statements.
* Validate all user input. Ensure that only expected and valid input is accepted. Do not sanitize potentially malicious input.
* Reduce the potential damage of SQLi attacks. Minimize the database user's privileges using the principle of least privilege.
* For detailed information and assistance on how to prevent SQL Injection vulnerabilities, see the [OWASP SQL Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html).
9 changes: 9 additions & 0 deletions docs/docs/d/web/user-enumeration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# User enumeration
## Description
Web applications sometimes indicate whether a username or e-mail address exists as a user. Two of the most common places this occurs are the web application's login page or the "forgot password" functionality. For example, users who enter incorrect credentials receive the information that their password was wrong. An attacker can now use the information to determine whether a particular username exists. An attacker can now use the data to specify a list of valid usernames.

Once attackers have such a list, they can address these user accounts in new attacks to obtain valid credentials. In its simplest form, an attacker could perform password-guessing attacks. Attackers can use large word lists containing frequently used passwords for this. An attacker could also use enumerated usernames to search past data leaks for passwords. Credentials from data leaks, consisting of pairs of usernames and passwords, can be reused by attackers in automated attacks. This particular form of brute force attack is also known as credential stuffing. Alternatively, an attacker can use usernames during social engineering campaigns to contact users.

## Recommendation
* Ensure the web application returns generic error messages when users enter invalid credentials.
* Ensure that web server response times are similar for valid and invalid user accounts.

0 comments on commit a2d87a8

Please sign in to comment.