The Django applications settings specifies "*" as an entry in the ALLOWED_HOSTS setting. This setting is used by django.http.HttpRequest.get_host() to validate the Host header. A value of "*" will allow any host in the Host header. An attacker may use this in cache poisoning attacks or for poisoning links in emails.

Example 1: An application offers a reset password feature where users can submit some kind of unique value to identify themselves (eg: email address) and then a password reset email will be sent with a link to a page to set up a new password. The link sent to the user can be constructed using the Host value to reference the site that serves the reset password feature in order to avoid hardcoded URLs. For example:

...
def reset_password(request):
  url = "http://%s/new_password/?token=%s" % (request.get_host(), generate_token())
  send_email(reset_link=url)
  redirect("home")
...

An attacker may try to reset a victim's password by submitting the victim's email and a fake Host header value pointing to a server he controls. The victim will receive an email with a link to the reset password system and if he decides to visit the link, she will be visiting the attacker-controlled site which will serve a fake form to collect the victim's credentials.

If cookie-based sessions are used and SECRET_KEY is leaked, an attacker will be able to store arbitrary data in the session cookie which will be deserialized in the server leading to arbitrary code execution.

If cookie-based sessions are used, take extra care to make sure that the secret key is always kept completely secret, for any system which might be remotely accessible.

Example 1: The following view method allows an attacker to steal the SECRET_KEY if it is hardcoded in settings.py configuration file:

...
def some_view_method(request):
  url = request.GET['url']
  if "http://" in url:
    content = urllib.urlopen(url)
    return HttpResponse(content)
  ...

Example 1 method checks that the url parameter is a valid URL by checking that "http://" is present in the URL. A malicious attacker may send the following URL to leak the settings.py configuration file that may contain the SECRET_KEY:

file://proc/self/cwd/app/settings.py#http://

Note: "/proc/self/cwd" in UNIX systems points to the process working directory. This allow attackers to reference files without knowing the exact location.

Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account.

If multiple threads are trying to obtain a lock on a resource, calling sleep() while holding a lock can cause all of the other threads to wait for the resource to be released, which can result in degraded performance and deadlock.

Example 1: The following code calls sleep() while holding a lock.

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();

Fingerprinting the technology underlying the target application allows attackers to:
1. Target security weaknesses resulting from insecure development practices commonly observed in applications based on detected technology

Example 1: Hardcoded credentials and encryption keys in Java applets
2. Exploit known security issues reported against the detected technology

The annotation FortifyDangerous has been applied to this type. This is used to indicate that it is dangerous and all uses should be examined for safety.

A handle is a reference that represents a system resource such as a portion of memory or a file. In this case, the code does not set the current object as the owner of the underlying handle, which fails to reliably release the handle after the object has been disposed.

Most unreleased resource issues result in general software reliability problems. However, if an attacker can intentionally trigger a resource leak, they can try to launch a denial of service by depleting the resource pool.

Example 1: The following code creates a new instance of SafeEvpPKeyHandle, but fails to reliably let the object release the handle during the finalization phase by setting the ownsHandle parameter to false.

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);

var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: false);

if (safeEvpHandle.IsInvalid) {
	...
}
safeEvpHandle.close();

At some point in every Java developer's career, a problem surfaces that appears to be so mysterious, impenetrable, and impervious to debugging that there seems to be no alternative but to blame the garbage collector. Especially when the bug is related to time and state, there may be a hint of empirical evidence to support this theory: inserting a call to System.gc() sometimes seems to make the problem go away.

In almost every case we have seen, calling System.gc() is the wrong thing to do. In fact, calling System.gc() can cause performance problems if it is invoked too often.

In most cases a direct call to a Thread object's run() method is a bug. The programmer intended to begin a new thread of control, but accidentally called run() instead of start(), so the run() method will execute in the caller's thread of control.

Example 1: The following excerpt from a Java program mistakenly calls run() instead of start().

    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };

  thr.run();

It appears that the programmer intended for this class to implement the Cloneable interface because it implements a method named clone(). However, the class does not implement the Cloneable interface and the clone() method will not behave correctly.

Example 1: Calling clone() for this class will result in a CloneNotSupportedException.

public class Kibitzer {
  public Object clone() throws CloneNotSupportedException {
    ...
  }
}

Do not explicitly deallocate stack memory. A function that defines a stack buffer will automatically deallocate the buffer when the function returns.
Example 1:

void clean_up()
{
    char tmp[256];
    ...
    free(tmp);
    return;
}

Explicitly freeing stack memory can corrupt memory allocation data structures. It can lead to abnormal program termination or further data corruption.

It is never a good idea for a web application to attempt to shut down the application container. A call to a termination method is probably part of leftover debug code or code imported from a non-J2EE application.

Deleting a managed pointer will cause the program to crash or otherwise do the wrong thing when, later on, the pointer management code assumes that the pointer is still valid. The following example illustrates the error.

  std::auto_ptr<foo> p(new foo);
  foo* rawFoo = p.get();
  delete rawFoo;

The only exception to this rule comes when a managed pointer class supports a "detach" operation allowing the programmer to take control of memory management for the given pointer. If the program detaches the pointer from the management class before calling delete, the management class knows not to use the pointer any further.

The _alloca() function allocates memory on the stack. If an allocation request is too large for the available stack space, _alloca() throws an exception. If the exception is not caught, the program will crash, potentially enabling a denial of service attack.
_alloca() has been deprecated as of Microsoft Visual Studio 2005(R). It has been replaced with the more secure _alloca_s().

A handle is a reference that represents a system resource such as a portion of memory or a file. In this case, the code fails to reliably release a handle by using the handle after it has been invalidated.

Most unreleased resource issues result in general software reliability problems. However, if an attacker can intentionally trigger a resource leak, they can try to launch a denial of service by depleting the resource pool.

Example 1: The following code creates a new instance of SafeEvpPKeyHandle, but calls the DangerousGetHandle after the handle has been invalidated by SetHandleAsInvalid, which potentially returns a stale handle value.

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);
var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: true);
...
safeEvpHandle.SetHandleAsInvalid();
...
var handle = safeEvpHandle.DangerousGetHandle();
...
safeEvpHandle.close();

Programmers often trust the contents of hidden fields, expecting that users will not be able to view them or manipulate their contents. Attackers will violate these assumptions. They will examine the values written to hidden fields and alter them or replace the contents with attack data.

Example 1:

  Hidden hidden = new Hidden(element);

If hidden fields carry sensitive information, this information will be cached the same way the rest of the page is cached. This can lead to sensitive information being tucked away in the browser cache without the user's knowledge.

Android Intents are used to bind applications and application components together by providing instruction on actions that a given component performs. Pending intents are created to deliver the Intent at a later time. Implicit intents facilitate the calling of intents from any given external component, using a general name and filter to determine execution.

When an implicit Intent is created as a PendingIntent, this might allow for the Intent to be sent to an unintended component that runs outside of the intended temporal context, leaving the system vulnerable to exploit vectors such as denial of service, private and system information leakage, and privilege escalation.

Example 1: The following code uses an implicit PendingIntent.

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...

Different operating systems use different characters as file separators. For example, Microsoft Windows systems use "\", while UNIX systems use "/". When applications have to run on different platforms, the use of hardcoded file separators can lead to incorrect execution of application logic and potentially a denial of service.

Example 1: The following code uses a hardcoded file separator to open a file:

...
File file = new File(directoryName + "\\" + fileName);
...

An internal Intent uses a custom action as defined by an internal component. Implicit intents can facilitate the calling of intents from any given external component without knowledge of the specific component. Combining the two allows for an application to access intents specified for a specific internal use from outside of the desired application context.

The ability to process an internal Intent from an external application can enable for a wide variety of man-in-the-middle exploits ranging in severity from information leakage and denial of service to remote code execution, depending on the capacity of the internal action specified by the Intent.

Example 1: The following code uses an implicit internal Intent.

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Allowing modification of the underlying Intent of a PendingIntent after its creation can leave a system open to attack. This mostly depends on the overall capability of the underlying Intent. In most cases, it is best practice to prevent potential issues by setting the PendingIntent flag to FLAG_IMMUTABLE.

Example 1: The following includes a PendingIntent created with a flag value of FLAG_MUTABLE.

...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
    this,
    0,
    intent_flag_mut,
    flag_mut
)
...