|
Last
week we discussed the first 9 (top 9) in the CWE Top 25 Most
Dangerous Programming Errors. This week, we'll discuss the second 8
on the list, which have been grouped into a category called “Risky
Resource Management”.
Risky Resource
Management
The weaknesses in this category are
related to ways in which software does not properly manage the
creation, usage, transfer, or destruction of important system
resources. The majority of the errors covered in this category are
more complex than the Top 9 (Insecure Interaction Between Components)
and –as such- can be more difficult to fully comprehend and
mitigate against.
#10
CWE-19: Failure to
Constrain Operations within the Bounds of a Memory Buffer
Usually referred to simply as a “Buffer
Overflow”, this class of attack has been with us for many years.
Although not frequently seen or publicized in most web application
technologies, almost all known web servers, application servers, and
web application environments are indeed susceptible to buffer
overflows, the notable exception being Java and J2EE environments,
which are immune to these attacks (except for overflows in the JVM
itself).
Anytime an application allocates a
memory buffer to store a variable or input supplied by an attacker,
the buffer could be vulnerable to overflow if proper input validation
is not performed. As an example, imagine a buffer set to hold 64
bytes of data. This buffer holds information provided by the user via
web-based form. If there is no input validation, entering a string of
96 bytes in length could effectively overflow the buffer.
Depending on what type of application
and what type of data (and many other factors) an attacker could use
the overflow data to execute code outside of the intended function of
the application, potentially resulting in the attacker gaining
complete control of the server or application.
#11
CWE-642: External
Control of Critical State Data
There are many ways to code your web
applications to maintain state information. Ever wonder why when you
return to a website (such as this one) that the application
“remembers” who you are? This is usually referred to as session
or “state” data, and there are various ways to accomplish this.
Typically this is done by setting a
Cookie variable in the user's browser that relates to a session
variable on the server. The problem is that oftentimes insecure or
unencrypted human-readable data can be used for this purpose, and -as
such- manipulated by an attacker to escalate privileges. Say for
example that a web application sets a Cookie called “Username”
set to the user's login ID once a user successfully authenticates. In
this example, we'll assume that user Mike authenticated to the web
application, and a Cookie named Username assigned the value of
“Mike”. What happens if I change the cookie stored in my browser
to “Username=admin”? In this primitive example, I would now have
admin rights to the site.
Cookie values aren't the only danger in
this category though. Oftentimes developers will utilize “hidden”
form field variables to store pertinent data about the user, session
or transaction. This data can also be manipulated by an attacker to
break the application or escalate privileges.
#12
CWE-73: External
Control of Filename or Path
Many web applications are coded on the
backend to utilize libraries, classes or files stored on the web
server. Additionally, some applications may allow user-supplied input
to specify which file or resource is interacted with. This type of
logic has been exploited many times over the past 15 years, most
commonly by pre-pending the input filename with “../../” or
similar, which allows an attacker to interact with files outside of
the intended directory.
Additionally some applications may
allow a user to input a URL or other external resource that is
processed or run by the web server in some fashion. Failing to use
proper input coding or file validation before processing can lead to
big problems. Making this worse, most system engineers will configure
the web server to run as the super user, or admin, account, which
means that any trickery by an attacker would result in administrative
access.
Running the web server as a non-admin
account and (for *nix servers) running the web server in a “jailed”
environment (chroot) would prevent any manipulation of the filename
to be limited in severity. Of course, though, input validation is a
key to mitigation with this error....never trust the data provided by
your users to be “trusted”.
#13
CWE-426: Untrusted
Search Path
Although similar to the previous error,
this one has more to do with the default trust relationship the web
server has within it's own environment. Servers running the web
applications have a series of trusted PATHs that are searched when
attempting to execute a file or locate a resource. On Windows
systems, for example, the PATH usually contains “C:\Windows\System32”
which contains applications that could cause serious harm if misused.
A common lazy programming technique is
to rely on environment variables to locate libraries or classes
utilized by the web application code. If an attacker can control the
environment variables, then they can cause your application to
execute malicious code. The best example of this is in shared web
hosting environments. Due to a flaw in the way the HOST headers are
utilized in a default installation of Apache, it is possible for one
web application on a shared server to access resources in the path of
another site hosted on the same server.
I demonstrated an example of this last
year on my personal blog (here) if you're interested in just how this
works.
#14
CWE-94: Code
Injection
It is common for robust, dynamic web
applications to pass data back and forth between external programs
and systems in order to execute complex processes which return output
back to the web application for display to the user.
A common PHP example is to use the
function fopen() to interact with a user-supplied file or to execute
a program on the system that interacts with user-supplied input. I
ran into a similar issue in an application I was writing last month
that took a user-supplied file and ran it through a perl script. When
troubleshooting an issue I realized that an improperly formatted
input file caused the perl script to die. I quickly realized that If
the right data was in the file, I could do more than cause the
backend script to die.
Again, input validation, correct
privileges and error-checking at each step of the way is necessary to
thwart these attacks.
#15
CWE-494: Download
of Code without Integrity Check
This error is less of a risk to your
web applications, and more of a risk to your users. Untrusted
downloads have led to massive virus outbreaks and system compromises.
Systems that don't employ anti-virus clients are particularly at
risk.
Since I don't have much to say on this
issue, if you are a software provider, digitally sign your
applications/downloads and provide an integrity-checking mechanism
for your users to identify valid versions of your code, vs malicious
software masquerading as your application.
#16
CWE-404: Improper
Resource Release or Shutdown
All dynamic web applications utilize
various applications and processes that require system resources or a
temporary data set (such as cookies and session variables). Failing
to dispose of running processes, allocated memory, or state data can
allow an attacker to gain access to information as a result.
From the system perspective, failing to
shutdown resources after use can lead to a denial of service or crash
of your system.
One simple example (for anyone who's
ever used Dreamweaver to write a dynamic application) is the use of
database hooks. For example, if writing a dynamic PHP application in
Dreamweaver, those database connections will automatically generate
the 'mysql_free_result' function at the end of your code. If you need
to modify the PHP code manually (which is usually the case) to setup
a nested repeat region, the mysql_free_result code stays improperly
stuck at the end of your code, rather than at the end of a loop or
elsewhere.....with enough queries in a short amount of time, you
could cause the application to crash.
#17
CWE-665: Improper
Initialization
This error has everything to do with
variables. When you create or call a variable in your application, it
either contains data or is NULL – it doesn't just happily exist
until you use it. For languages that simply initialize a variable as
NULL, what happens when your application isn't configured to handle
NULL values? Or worse, if your application fails to shutdown
resources (CWE-404) it is possible that a variable can hold data from
a previous user's session.
The basic gist of the error is to
assign (initialize) all of your applications variables with a default
value. This ensures that un-supplied (NULL) data or previous data
cannot be introduced into your application.
#18
CWE-682: Improper
Calculation
Have you ever seen Superman III or the
Office Space? In both of these movies a programmer figured out a way
to handle rounded-off digits to siphon money into a 3rd
party account. This was because in both instances, the application
only utilized 2 digits after the decimal, either rounding up or down
(or not at all).
Take for example, the simple
calculation of 3 divided by 2. The answer is
0.66666666666666666666666666666667. Most applications and databases,
however, will round off to only 2 trailing digits (0.67 or 0.66
depending on the way the application is coded). What happens to all
those remaining digits?
What if your application uses
mathematical calculations for other purposes, and relies on
user-supplied input? What if an attacker enters a Zero instead of any
otherwise-anticipated value? Unexpected things are sure to occur.
Once again, Input Validation is the key
to many of the Errors in this category.
Next week, we'll round out this series
by discussing the final 7 issues, categorized as “Porous Defenses”
Only registered users can write comments.
Please login or register. |
