Vulnerability of the Day

Buffer Overflow

Description. See CWE-120

Example: stack-buffer-overflow.zip

Mitigations: Keep track of your array sizes. Check the size of your buffer as it is inputted. In the case of C, use functions like strncpy() instead of strcpy() . Avoid functions like gets that don't check the input size.

Notes

Integer Overflow

Description. See CWE-190

Examples: integer-overflow.zip. Also for an interesting example from Firefox, check out the CVE-2010-2753, and corresponding bugzilla, especially the patch to fix.

Mitigations:

Notes

SQL Injection

Description. See CWE-89

Examples: sql-injection.zip.

Mitigations:

Notes

OS Command Injection

Description. See CWE-78

Examples:

Mitigations:

Notes

Hard-coded Credentials

Description. See CWE-798

Examples: hardcoded-credentials.zip

Mitigations:

Notes

Log overflow

Description. See CWE-400 for a general description. Related CWEs are CWE-779 and CWE-770. Printing out to a console or logger usually ends up in a text file. If an attacker knows this, and the logging is unrestricted, then attackers can fill up the log file and crash the machine by filling up the hard drive. This is a denial of service attack that is particularly difficult to recover from. Plus, weird things happen when the entire hard drive is completely out of bytes, so attackers can take advantage of this.

Examples: log-overflow.zip. Linux kernel has had this issue as well.

Mitigations:

Notes

Path Traversal

Description. See CWE-22

Examples: path-traversal.zip. Also, see this issue (CVE-2009-2902) or its entry in the CVE in Tomcat where they allowed web applications be named "...war", which could be used for arbitrary file deletion outside of the webapp sandbox.

Mitigations:

Notes

Cross-Site Scripting (XSS)

Description. See CWE-79

Examples: Use the XAMPP installation as described in the web applications activity.

Mitigations:

Notes

Cross-Site Request Forgery (CSRF)

Description. See CWE-352. Another good description. Essentially, when an HTTP GET request makes a persistent modification, then you can get users to make changes to other websites they are already authenticated into.

Examples: Use the given XAMPP with DVWA to construct a CSRF attack. An example exploit would be getting a user to load an HTML page with this image:

<img src="http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=12345&password_conf=12345&Change=Change#">

Mitigations:

Notes

Open Redirect

Description. See CWE-601

Examples:

Mitigations:

Notes

Hashing and Salt

Description. See CWE-759. If an attacker breaks in to a system that provides authentication, they should not be able to access the passwords. Historically, people would hash (digest) algorithms to accomplish this. However, commonly-guessed passwords are still vulnerable, as attackers can make "rainbow tables", or digests of common passwords.

Examples:

Mitigations:

Notes

Log Neutralization

Description. See CWE-117. If you allow newlines in your logs, then attackers can forge log entries, throwing investigations off. Related to generalized CRLF Injection ( CWE-93)

Examples:

Mitigations:

Notes

Java Reflection Abuse

Description. See CWE-470. Despite what you might assume, Java allows you to access private variables in other classes via its Reflection API. In untrusted API situations (e.g. plug-in architectures), this can lead to malicious libraries accessing and tampering with sensitive data.

Examples:

Mitigations:

Notes

Uncontrolled Format String

Description. See CWE-134. In C, printing using printf(str) instead of printf("%s", str) results in the user being able to control the format string. This is especially egregious when you look at the %x and %n codes, which allow users to read and write arbirary bytes to arbitrary memory locations.

Examples:

Mitigations:

Notes

XML Embedded DTDs

Description. See CWE-827. XML allows for validation of their input using Document Type Definitions (DTDs). These DTDs are pretty flexible, and allow for things like reading in external files. However, users can embed their own DTDs in the header of an XML file, thereby accessing the file system directly.

Examples: xml-dtd.zip.

Mitigations:

Notes

Insecure PRNG Algorithms

Description. See CWE-338. Most pseudo-random number generators (PRNGs) are not designed to be secure, and with improper management can be easily guessed by a variety of methods.

Mitigations:

Lack of PRNG Seed Protection

Description. See CWE-338. If you are using PRNGs for security purposes (e.g. encryption keys, session tokens, unique tokens), don't make those seeds easily guessable.

Examples:

  • Don't use predictable seeds, such as: Instead, have the user set a secret token upon installation, and protect that secret token. Consider that token to be an asset, much like the salt for hashes.
  • Notes

    Cache Poisoning

    Description. See the CAPEC-141 attack pattern.

    Examples:

    Mitigations:

    Notes

    Time of Check, Time of Use (TOCTOU)

    Description. See CWE-367.

    Examples:

    Mitigations:

    Notes

    Compression Bombs

    Description

    See CWE 409. Also libpng has a great discussion

    Similar to an XML bomb, compression bombs are primarily used for denial of service attacks by filling up RAM or hard disk space. Minimally, this crashes the process and causes denial of service. Crashes, if handled poorly, however, can also cause other integrity problems (e.g. data corrpution), or confidentiality problems (e.g. core dumps).

    What is more challenging about compression bombs is how ubiquitous compression is, and how hard this is to validate. If you are doing input validation, then you probably need to decompress first, so your decompression library is on the front lines of your attack surface.

    Example

    Mitigations

    Notes