SANS Top 20 Security Vulnerabilities In Software Applications

Learn and understand the SANS top 20 Critical Security Vulnerabilities in Software Applications with examples in this tutorial:

The word SANS is not just an ordinary dictionary word rather it stands for SysAdmin, Audit, Network, and Security.

In this tutorial, we will learn about the SANS top 20 security weaknesses we can find in software programs and what we can do to mitigate it.

SANs Impact On Cyber Security Community

According to SANS, the SANS Institute was established as a research and education organization. Its various security programs are very comprehensive and are having a positive effect on over 165,000 security professionals globally.

We can rightly say that with this kind of coverage coming from SANS and other positive review they get makes them the most trusted and by far the largest organization for InfoSec training and various security certification in the world.

This article will focus on the SANS top 20 errors that can make your software vulnerable to attack and some of the security controls you can implement to mitigate against these errors. Though we can find more than 20, but we will discuss the top 20 vulnerabilities.

List Of SANS Top 20 Critical Vulnerabilities In Software

1. CWE-119: Memory Buffer Error
2. CWE-79: Cross-site Scripting
3. CWE-20: Unvalidated Input Error
4. CWE-200: Sensitive Information Exposure Error
5. CWE-125: Out-of-bounds Read Error
6. CWE-89: SQL Injection
7. CWE-416: Free Memory Error
8. CWE-190: Integer Overflow Error
9. CWE-352: Cross-Site Request Forgery
10. CWE-22: Directory Traversal
11. CWE-78: OS Command Injection
12. CWE-787: Out-of-bounds Write Error
13. CWE-287: Improper Authentication Error
14. CWE-476: Dereferencing NULL Pointer
15. CWE-732: Incorrect Permission Assignment
16. CWE-434: Unrestricted File Upload
17. CWE-611: Information Exposure through XML Entities
18. CWE-94: Code Injection
19. CWE-798: Hard-coded Access Key
20. CWE-400: Uncontrolled Resource Consumption

What the term CWE means?

The Common Weakness Enumeration (CWE) is a community accepted list of software and hardware vulnerabilities with identification code assigned for each weakness. The goal is to identify various flaws in software and hardware to be able to fix and mitigate all those flaws.

#1) CWE-119: Memory Buffer Error

This flaw is usually introduced during Architecture and Design, Implementation, Operation stages of the SDLC.

This buffer overflow happens when an application process tries to store more data than it can hold in the memory. Since the buffers can only store some level of data and when that level is reached and exceeded, the data flows to another memory location which can corrupt the data already contained in that buffer.

This incident sometimes happens accidentally through some programming error, but the aftereffect could be disastrous, as this can erase data, steal confidential information, and even the whole application could crash because of this buffer overflow.

The example below shows a buffer allocated with 8bytes storage. But it overflowed by 2bytes because of more data was sent for execution.

[image source]

#2) CWE-79: Cross-site Scripting

Cross-site Scripting (XSS) is an injection attack that usually happens when a malicious actor or an attacker injects malicious or harmful script into a web application which can be executed through the web browsers. Once the malicious script finds its way into the compromised system, it can be used to perform different malicious activities.

Some of the malicious activities can be in the form of transferring private information like cookies that have the session information from the victim’s computer to the attacker’s computer.

Cross-site scripting occurrence:

• When un-validated and un-trusted data are inputted into a web application through the web form request.
• When the web application instantly output a web page that contains this malicious data.
• During the process of generating a page, the software fail to validate against the data, which house the content that can be executed by a web browser, like HTML and JavaScript.
• The victim unknowingly visits the page that was generated through a web browser, that house the malicious script that was injected through the use of the untrusted data.
• The malicious script comes from a page that was sent by the attacker’s web server, the compromised system web browser then goes ahead to process the malicious script.
• This action violates the web browser’s policy about same origin, which stipulates that scripts coming from one domain should not have access to resources or execute code in another different domain except its own domain.

[image source]

#3) CWE-20: Unvalidated Input Error

The application receives input, but fails to validate the input, whether it has all necessary details needed for it to be accepted into the system for processing.

When there is input sanitization, this can be used to check any potentially dangerous inputs in order to ensure that the inputs are safe to be processed with the source code or when it’s an input that is needed to communicate with other components.

When such inputs are not properly sanitized or validated, then this will pave way for an attacker to send a malicious input that the main application will generously process and this will lead to changes in the control flow, arbitrary control of a resource, or arbitrary code execution.

The below images show that a good application should not accept script or command as an input. If such inputs are not properly sanitized, the application will process it thinking it’s a valid request.

[image source]

#4) CWE-200: Sensitive Information Exposure Error

This happens when the application knowingly and unknowingly exposes information that is confidential and sensitive to an attacker who does not have the authorization to access these information.

Different errors lead to this information being exposed to an attacker. The severity of this error varies according to the context in which the application operates, the type of sensitive information that is revealed, and what the actor can gain from the exposed information.

Below are some sensitive information that could be exposed:

• Personal information like personal messages, financial data, health status records, geographic location, or contact details
• System configuration details and environment, for example, the operating system and installed packages
• Business Record and intellectual property
• Network configuration details
• Internal application state
• Metadata like the message headers

Sometimes there could be technical itches like database connectivity error, run-time error, and network error on our applications or websites.

If such errors are not properly handled during development, i.e. when the application displays the error message it could display information to the public which an attacker may be able to use for malicious purposes like the image below.

#5) CWE-125: Out-of-bounds Read Error

This usually occurs when the application reads data past the normal level, either to the end or before the beginning of the buffer. This gives unprivileged access to an attacker to read sensitive information from other memory locations, which can as well leads to a system or application crash.

A crash will certainly happen when the code reads data and thinks there is an indicator in place that stops the read operation like a NULL that is applied to a string

In the following code, the function retrieves a value from an array index location, which in turn is the input parameter to the function.

[image source]

From the code above, we can see that the function verifies that the given array index is less than the maximum length of the array, but fails to validate for the minimum value.

This un-validation will lead to the acceptance of a negative value as an input array index, causing an out-of-bounds read, which in turn gives access to sensitive memory.

There is a need to verify the input array index if it is within the maximum and minimum range required for the array.

If you now check the below example, you will see that the IF statement needs to be modified to include a minimum range validation.

#6) CWE-89: SQL Injection

SQL injection is a form of security vulnerability whereby the attacker injects a Structured Query Language (SQL) code to the Webform input box in order to gain access to resources or change data that is not authorized to access.

This vulnerability can be introduced to the application during the design, implementation, and operation stages.

What this SQL query does is to make an unauthorized request to the database for some information. In a normal input operation, a Web form is used for user authentication. When a user enters their name and password into the text boxes, these values are inserted into a SELECT query.

If the input values are correct, the user is granted access to the application or request, but if the values are incorrect, access will be denied.

Some Web forms today do not have mechanisms in place to block malicious input an attacker can use the input boxes to send malicious requests to the database. This single request can grant them access to the entire database that can contain sensitive information.

#7) CWE-416: Previously Freed Memory

This issue is caused by the referencing of memory after it has been released, which can seriously lead to a program crash. When you use a previously freed memory, this can have adverse consequences, like corrupting of valid data, arbitrary code execution which is dependent on the flaw timing.

Two common causes are:

• Error conditions within the software and in some other exceptional cases.
• No explanation as to which part of the program caused the free memory.

In this instance, the memory is allocated to another pointer immediately after it has been freed. The previous pointer to the freed memory is used again and now points to somewhere around the new allocation. By the time the data is changed, this can corrupt the used memory and could make the application behave in an undefined way.

#8) CWE-190: Integer Overflow Error

When a calculation is processed by an application and there is a logical assumption that the resulting value will be greater than the exact value, integer overflow happens. Here, an integer value increases to a value that cannot be stored in a location.

When this happens, the value will usually wrap to become a very small or negative value. If the wrapping is expected, then it’s fine, but there can be security consequences if the wrap is unexpected. When this scenario occurs, it could be termed critical as the result is used to manage looping, security decision, used to allocate memory, and many more.

This weakness will generally lead to erratic behavior and can lead to crashes. If the value is important to data than to flow, then a simple data corruption can occur. But if the wrap around leads to further conditions like buffer overflows, then memory corruption may happen.

This issue can trigger buffer overflows, which can be used to execute arbitrary code by an attacker. This integer overflow error is usually introduced into the system during the Design and Implementation stages of the SDLC.

#9) CWE-352: Cross-Site Request Forgery

This is when a web application does not sufficiently verify the HTTP request, whether the request was actually coming from the right user or not. The webservers are designed to accept all requests and to give a response to them.

Let’s assume a client sends several HTTP requests within one or several sessions. It is very difficult for a webserver to know whether all the requests were authentic or not, and it’s usually processed. An attacker may have its way of forcing a client to visit a specially crafted webpage and now be able to perform some requests like fund transfer, changing their email address, and many more.

Immediately an attacker has access and they will be able to steal data and can even destroy data. They can always maintain their access and when they are done, can compromise the audit log to prevent any future forensic that could expose their exploit.

The below image shows an attacker inducing a user to perform actions that they do not intend to perform.

#10) CWE-22: Directory Traversal

Directory traversal or file path traversal is a web security vulnerability that allows an attacker to read arbitrary files on the server that is currently running an application.

These files could be an application code, credentials for back-end systems, and the operating system files. In some other scenario, an attacker might be able to write to these arbitrary files on the server which could allow them to modify application data or behavior, and this will give them total control of the server.

[image source]

#11) CWE-78: OS Command Injection

It is about the improper sanitization of special elements that may lead to the modification of the intended OS command that is sent to a downstream component. An attacker can execute these malicious commands on a target operating system and can access an environment to which they were not supposed to read or modify.

This invariably would allow an attacker to execute dangerous commands directly into the operating system.

Whenever this vulnerability occurs in a privileged program, it allows the attacker to use commands that are allowed in the environment or to call other commands with privileges that the attacker does not have, which could increase the amount of damage that could occur.

#12) CWE-787: Out-of-bounds Write Error

This happens when the application writes data past the end, or before the beginning of the designated buffer.

When this happens, the end result is usually data corruption, system, or application crash. What the application does is some sort of pointer arithmetic that is used in referencing a memory location outside the buffer boundaries.

#13) CWE-287: Improper Authentication Error

This is when an attacker claims to have a valid identity but the software failed to verify or proves that the claim is correct.

A software validates a user’s login information wrongly and as a result, an attacker could gain certain privileges within the application or disclose sensitive information that allows them to access sensitive data and execute arbitrary code.

#14) CWE-476: Dereferencing A NULL Pointer

Dereferencing a null pointer is when the application dereferences a pointer that was supposed to return a valid result instead returns NULL and this leads to a crash. Dereferencing a null pointer can happen through many flaws like race conditions and some programming error.

The processes that are performed with the help of the NULL pointer usually lead to failure, and the possibility of carrying out the process is very slim. This helps attackers to execute malicious code.

[image source]

#15) CWE-732: Incorrect Permission Assignment

This vulnerability happens when an application assigns permissions to a very important and critical resource in such a manner that exposed the resource to be accessed by a malicious user.

When you give many people permission to a resource, this could lead to sensitive information being exposed or modified by an attacker. If there are no checks in place against this kind of approach to permission assignment to resources, it can lead to a very disastrous end if a program configuration or some sensitive data gets into the wrong hand.

#16) CWE-434: Unrestricted File Upload

This vulnerability occurs when the application does not validate the file types before uploading files to the application. This vulnerability is language independent but usually occurs in applications written in ASP and PHP language.

A dangerous type of file is a file that can be automatically processed within the application environment.

The following program shows an upload of a PHP file. The file type was not verified and validated before uploading within the webroot directory. As a result of this weakness, an attacker may upload an arbitrary PHP file and execute it by directly accessing the uploaded file.

#17) CWE-611: Information Exposure Through XML Entities

When an XML document is uploaded into an application for processing and this document contains XML entities with uniform resource identifier that resolves to another document in another location different from the intended location. This anomaly can make the application to attach incorrect documents into its output.

The XML documents sometimes contain a Document Type Definition (DTD), which is used to define the XML entities and other features. Through the DTD, the uniform resource identifier can serve as a form of substitution string. What the XML parser will do is access what is contained in the uniform resource identifier and input these contents back into the XML document for execution.

[image source]

#18) CWE-94: Code Injection

The existence of code syntax in the user’s data increases the attacker’s possibility to change the planned control behavior and execute arbitrary code. This vulnerability is referred to as “injection weaknesses” and this weakness could make a data control become user-controlled.

This vulnerability depicts a scenario where software allows untrusted data into the code and does not perform validation of special characters which can negatively influence both the behavior of the code segment and the syntax.

In short, an attacker would be able to inject some sort of arbitrary code and execute them within the application. The following PHP code shows the usage of the eval() function in untrusted data. In the code below an attacker is able to pass into the code the “param” parameter arbitrary code which will then be executed in the software.

The below example explain the call to the phpinfo() function. This vulnerability can further be exploited in other to execute arbitrary OS commands on the target software through the system() call.

#19) CWE-798: Hard-coded Access Key

This is when the password and access key is hard coded into the application directly for inbound authentication purpose and outbound communication to some external components and for encryption of internal data. Hard-coded login details usually cause vulnerability that paves the way for an attacker to bypass the authentication that has been configured by the software administrator.

The system administrator will always find it very hard to detect this vulnerability and fix it.

There are two main streams to this weakness:

• Inbound: The application contains an authentication system that validates the input credentials against the hard-coded details.
• Outbound: The application connects to another system and details for connecting to the other system are hardcoded into the system.

In the Inbound stream, there is always a default administrator’s account that is created, and the credentials to access it will be hard-coded into the application and associated with that default admin account.

The hard-coded details is usually the same thing across every installation of the application, and this cannot be changed or disabled by anyone. Even the system administrators do not have the right, except they can manually modify the application. If the password is ever disclosed to the public, then an attacker can have access to the entire application and can manipulate it for his own gain.

Since all installations of the application have the same password, even when installed in separate organizations, this can cause very massive attacks across all borders of the organization, for example, injecting a worm into the application which will spread around.

The Outbound stream only applies to front-end systems that authenticate with a back-end service. The back-end service may require a hard-code or fixed password which can be easily discovered. What the programmer does is simply to hard-code those back-end credentials into the front-end software. Any user of that application may be able to extract the password out.

Any client-side software where the password and access key is hard-coded into it usually poses more threat than those not hard-coded, because the extraction of a password from a binary is usually very easy to accomplish.

#20) CWE-400: Uncontrolled Resource Consumption

This vulnerability happens when the application does not control the allocation properly and maintenance of a limited resource, this allows an attacker to be able to influence the amount of resources consumed, which will eventually lead to the exhaustion of available resources.

Part of the limited resources includes memory, file system storage, database connection pool entries, and CPU.

Let’s assume an attacker can trigger the allocation of these limited resources and the number or size of the resources is not controlled, then the attacker could cause chaos through denial of service that consumes all available resources.

When this happens, it would prevent valid users from accessing the application, which will invariably have a negative impact on the environment. For instance, when the application memory goes through an exhaustion attack, this could slow down the entire application as well as the host operating system.

The three different instances which can lead to resource exhaustion are:

• Shortage of throttling for the number of allocated resources
• Losing out all references to a resource before reaching the shutdown stage
• Failure to close/returning a resource after processing

The issue of resource exhaustion is usually as a result of incorrect implementation of the following scenarios:

• Error conditions and other exceptional circumstances.
• There is mixed reaction over which part of the program releases the resource.

The following example helps to demonstrate the nature of this vulnerability and describe methods that can be used to mitigate the risk.

The following example explains the vulnerability:

[image source]

This program does not track how many connections have been made, and it does not limit the number of connections available. Forking is just one of the ways used by an attacker to cause the system to run out of CPU, processes, or memory by making a large number of connections.

What an attacker does is to consume all available connections, preventing others from accessing the system remotely.

Frequently Asked Questions

Q #1) What does SANS stand for?

Answer: SANS stands for SysAdmin, Audit, Network, and Security.

Q #2) Enlist some examples of vulnerabilities.

Answer: The examples are as follows:

• Software Vulnerabilities
• Firewall Vulnerabilities
• Network Vulnerabilities
• Operating System Vulnerabilities
• Web Server Vulnerabilities
• Database Vulnerabilities

Q #3) What is the difference between threats and vulnerabilities?

Answer: Threat is the possibility of carrying out a malicious or unwanted act in an attempt to damage a computer system or application through existing vulnerabilities in the system. Example: ransomware.

Vulnerabilities are weaknesses that exist within a system that could have allowed unwanted or unauthorized access from an attacker to infiltrate harm to an organization. Example: Firewall misconfiguration.

Q #4) What are the most common vulnerabilities?

Answer: These are as follows:

• SQL Injection
• Cross-Site Scripting
• Security Misconfiguration
• Sensitive Data Exposure
• Broken Authentication
• Session Management

Conclusion

This SANS top 20 vulnerabilities list is not a rule or policy, but a guide to assist us on how to avoid software vulnerabilities. Whether we are a developer or security expert, it is now left to us to follow this guide on what can be done to avoid any mistake that could lead to vulnerabilities in our application which can create a backdoor for an actor to execute a malicious act.