Inspired by this post we should list the real-world examples that we've came accross that fit into these categories.

---

1. Buffer Overflows

Stack Overflow

Vulnerable code:

		 int main(int argc, char *argv[])
		 {
		    char buffer[500];
		    strcpy(buffer, argv[1]);
		    return 0;
		 }
	

In this example, the user supplies input via the commandline (argv1) that is copied into a fixed-size buffer using the strcpy function.

Note that the call to strcpy does not specify the size of the buffer: if the string passed via the commandline is longer than 500 bytes, strcpy will write data into memory beyond the buffer. For variables declared on the stack, this adjacent memory contains the return address of the calling function.

An attacker can enter a specially crafted input that overwrites this return address, and executes some 'shellcode' included in the input. If the program runs with high privilges, e.g. as SYSTEM or Administrator, the injected code will execute in the context of that user.

---

2. Format String problems
Enter real-world examples here

---

3. SQL injection

Bypassing authentication

Many sites use the following code directly in a web page to authenticate users:

		 strSQL = "SELECT * FROM Users WHERE [UserName] = '" + [txtUserName] + "' "
		 strSQL = strSQL + "AND Password = '" + txtPassword + "'"
	

When not validating the txtUserName & txtPassword values, it allows users to enter text that can alter the intention of the SQL command.

For example, if a user enters <' OR 1=1 --> ( not including the < > ) into the txtUserName field. Left unchecked, the SQL command will become:

		 SELECT * FROM Users WHERE [UserName] = _ OR 1=1 --' AND Password = _
	

Notice the --, which disregard the rest of the statement as comments. Depending on your system, this could allow the users to enter the secured system.

Deleting Data

if a user enters <'; DROP TABLE Users; --> ( not including the < > ) into the txtUserName field. Left unchecked, the SQL command will become:

		 SELECT * FROM Users WHERE [UserName] = _; DROP TABLE Users; --' AND Password = _
	

Notice the ; which is the syntax for the beginning of another statement. Any SQL statement can be executed here, including that DROP TABLE you see there.

---

4. Command injection
Enter real-world examples here

---

5. Failure to handle errors

Here's a really simple batch file example...

C:
CD \Some\Path\That\Doesn't\Exist
Del .

...vs. a safer...

Del CD \Some\Path\That\Doesn't\Exist\.

The above is safer as it fails in a safer way.

---

6. Cross-site scripting
Enter real-world examples here

---

7. Failing to protect network traffic
Enter real-world examples here

---

8. Use of "magic" URLs and hidden forms
Enter real-world examples here

---

9. Improper use of SSL
Enter real-world examples here

---

10. Use of weak password-based systems
SQL Server 2000 : Allowing users (including System Administrators) to use SQL Server Security with Blank Passwords.

A related bug is the following "optional" password logic:
- passwords are optional
- if no password, password is left blank
- to change password, first enter existing password

To be safe, the above should really be considered "mandatory password" with a safety abyss bug on the side. Else if you've chosed not to have a password, I can DoS you by setting my own choice of password that locks you out

Here's a classic example of bad password logic from XP Pro:
- user account passwords are optional
- if no password, password is left blank
- Tasks won't run with a blank password
- therefore to make Tasks work, use a trivial password
- any non-null password exposes admin shares to network access

See the problem? If I have no interest in account passwords, I'd normally leave the password blank, and XP Pro would therefore not expose my hidden network shares. But to get Tasks to work *1, I must have a non-blank password, so I choose something trivial. Now I'm exposing hidden admin shares under a trivial password.

*1 XP RTM didn't have the subsequently-added "run only when logged on" checkbox that provides a way to run Tasks with no password

---

11. Failing to store and protect data
Enter real-world examples here

---

12. Information leakage
Enter real-world examples here

---

13. Improper file access
Enter real-world examples here

---

14. Integer range errors
Enter real-world examples here

---

15. Trusting network address information
Enter real-world examples here

---

16. Signal race conditions

Applications often have logic to detect instances that are already running, if they are written to work only one instance at a time.

But this logic often takes a while to become effective, creating the risk of race conditions when two instances are launched within a small period of time. The first instance hasn't become visible to the second instance at the time the second instance checks for previously running instances, so you end up with two instances "successfully" launched.

Now add a UI that is ambiguous as to whether icons launch on single or double click, such as QuickLaunch (where intuitively, you may expect double-click to launch, a la Desktop). If a single-click icon is double-clicked, you're pretty sure to have launched two instances within a small period of time, and the race condition kicks in.

Another UI failure is where double-clicked icons show no visiual feedback that they have been launched, e.g. icons on the Desktop. If the app is slow to launch, you may assume your double click did not "take" (mouse moved between clicks, double-click wasn't fast enough) and you'd double-click again, and there may be that race condition again.

As an example of this failure, consider Win9x's "Specify a new..." mode fpr .pif that are set to run in MS-DOS Mode. When launched, the existing (system) Config.sys and AutoExec.bat are copied to .wos backups, and the .pif's private alternatives are extracted into place. The second instance does the same thing, so when you Exit the session, the .wos files that are restored will be those from the first instance, and you get "trapped in DOS".

---

17. Unauthenticated key exchange
Enter real-world examples here

---

18. Failing to use cryptographically strong random numbers
Enter real-world examples here

---

19. Poor usability
Enter real-world examples here

---