Input validation and representation problems ares caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input. The issues include: "Buffer Overflows," "Cross-Site Scripting" attacks, "SQL Injection," and many others.
send
function and its variants allow programmers to work around Ruby access specifiers on functions. In particular it enables the programmer to access private and protected fields and functions, behaviors that are normally disallowed.paramName
URL parameter.
...
<bookmark>
<method>#{paramHandler.handleParams}</method>
<url-parameter>
<name>paramName</name>
<value>#{requestScope.paramName}</value>
</url-parameter>
</bookmark>
...
userClassPath
to determine the directory in which to search for classes to load.
...
productCategory = this.getIntent().getExtras().getString("userClassPath");
DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
...
userClassPath
to point to a different path, which they control. Because the program does not validate the value read from the environment, if an attacker can control the value of userClassPath
, then they can fool the application into pointing to a directory that they control and therefore load the classes that they have defined, using the same privileges as the original app.userOutput
to determine the directory the optimized DEX files should be written.
...
productCategory = this.getIntent().getExtras().getString("userOutput");
DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...
userOutput
to a directory that they control, such as external storage. Once this is achieved, it is simply a matter of replacing the outputted ODEX file with a malicious ODEX file to have this executed with the same privileges as the original application.ModelState.IsValid
to check if model validation passes.class.classLoader
that enable them to override system properties and potentially execute arbitrary code.
String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);
strncpy()
, can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.gets()
function to read an arbitrary amount of data into a stack buffer. Because there is no way to limit the amount of data read by this function, the safety of the code depends on the user to always enter fewer than BUFSIZE
characters.Example 1.b: This example shows how easy it is to mimic the unsafe behavior of the
...
char buf[BUFSIZE];
gets(buf);
...
gets()
function in C++ by using the >>
operator to read input into a char[]
string.Example 2: The code in this example also relies on user input to control its behavior, but it adds a level of indirection with the use of the bounded memory copy function
...
char buf[BUFSIZE];
cin >> (buf);
...
memcpy()
. This function accepts a destination buffer, a source buffer, and the number of bytes to copy. The input buffer is filled by a bounded call to read()
, but the user specifies the number of bytes that memcpy()
copies.
...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
...
lccopy()
takes a string as its argument and returns a heap-allocated copy of the string with all uppercase letters converted to lowercase. The function performs no bounds checking on its input because it expects str
to always be smaller than BUFSIZE
. If an attacker bypasses checks in the code that calls lccopy()
, or if a change in that code makes the assumption about the size of str
untrue, then lccopy()
will overflow buf
with the unbounded call to strcpy()
.Example 4: The following code demonstrates the third scenario in which the code is so complex its behavior cannot be easily predicted. This code is from the popular libPNG image decoder, which is used by a wide array of applications.
char *lccopy(const char *str) {
char buf[BUFSIZE];
char *p;
strcpy(buf, str);
for (p = buf; *p; p++) {
if (isupper(*p)) {
*p = tolower(*p);
}
}
return strdup(buf);
}
png_crc_read()
. However, immediately before it tests length, the code performs a check on png_ptr->mode
, and if this check fails a warning is issued and processing continues. Since length
is tested in an else if
block, length
would not be tested if the first check fails, and is used blindly in the call to png_crc_read()
, potentially allowing a stack buffer overflow.Example 5: This example also demonstrates the third scenario in which the program's complexity exposes it to buffer overflows. In this case, the exposure is due to the ambiguous interface of one of the functions rather than the structure of the code (as was the case in the previous example).
if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);
getUserInfo()
function takes a username specified as a multibyte string and a pointer to a structure for user information, and populates the structure with information about the user. Since Windows authentication uses Unicode for usernames, the username
argument is first converted from a multibyte string to a Unicode string. This function then incorrectly passes the size of unicodeUser
in bytes rather than characters. The call to MultiByteToWideChar()
may therefore write up to (UNLEN+1)*sizeof(WCHAR)
wide characters, or(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR)
bytes, to the unicodeUser
array, which has only (UNLEN+1)*sizeof(WCHAR)
bytes allocated. If the username
string contains more than UNLEN
characters, the call to MultiByteToWideChar()
will overflow the buffer unicodeUser
.
void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
MultiByteToWideChar(CP_ACP, 0, username, -1,
unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}
strncpy()
, can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.c
because the double
type requires more space than is allocated for c
.
void formatString(double d) {
char c;
scanf("%d", &c)
}