Vunerabilities And Risky Resource Management Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.


Vulnerability is a weakness in a system which allows an attacker to reduce the systems assurance level. ISO 27005 defines vulnerability as: [3]

A weakness of an asset or group of assets that can be exploited by one or more threats, where an asset is anything that can has value to the organization, its business operations and their continuity, including information resources that support the organization's mission[4]

Vulnerabilities are classified according to the asset they are related to. For example hardware, software, network etc. Software Vulnerabilities are at the root of most security problems on the internet. Such vulnerabilities are often caused by software bugs (e.g. an unchecked buffer or a race condition) or software features (e.g. executable attachments to e-mail, uploading files etc.). The weaknesses can be categorized into following categories:

Insecure Interaction between components: The weakness is related to the insecure data interaction between separate components, programs, processes or systems.

Risky Resource Management: The weakness is related to improper management of the system resources.

Porous Defenses: The weakness is related to misuse defensive techniques.

AIM: The aim of this project is to make investigation of software vulnerabilities. The 2010 CWE/SANS Top 25 Most Dangerous Software Errors list has been used to select the most widespread and critical programming errors that can lead to serious software vulnerabilities.

Scope: A detailed investigation of the selected software vulnerabilities is included in the report. The vulnerabilities chosen are relevant to the networked systems. In the analysis, the nature of the weakness, its occurrence and its consequences have been discussed. Later countermeasures have been given which include both prevention and detection techniques. The severity of the vulnerability is elaborated by giving following details:

Attack frequency (How often a vulnerability is exploited by the attacker)

Ease of detection (How easily a weakness is detected by the attacker)

Remediation cost (Effort to fix the weakness) and

Attacker awareness (Likelihood that an attacker is aware of weakness, its detection methods and ways to exploit it).

The report also discusses the usefulness of list of programming errors.

Improper Neutralization of Input during Web Page Generation (Cross Site Scripting)

Cross-site Scripting (XSS) is one of the most common and dangerous computer security vulnerability typically found in web applications. It enables an adversary or malicious attacker to inject client-side script into web pages viewed by other users. In general, the software does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page, served to other users. An attacker exploits this vulnerability and launches an attack to perform malicious activities.

How it occurs?

An attacker takes advantage of a Web site vulnerability, in which content is displayed on the site that includes un-sanitized user-provided data. For example, an attacker might place a hyperlink with an embedded malicious script into an online discussion forum. Purpose of the malicious script is to attack other forum users who happen to select the hyperlink. For example it could copy user cookies and then send those cookies to the attacker.

Cross-site scripting (XSS) vulnerabilities occur when:

Un-sanitized data enters a web application, typically from a web request.

Web pages are generated dynamically from this un-sanitized data.

During Web page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.

A victim visits through the web browser, the generated web page that contains malicious script, injected using un-sanitized data.

As the script comes from a web page that was sent by the web server, the victim's web browser executes the malicious script in the context of the web server's domain.

This effectively violates the intention of the web browser's same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain.

Web application vulnerabilities allow attackers to get a user's browser to execute his/her code. This is a cross-site scripting hole that allows the attackers code to run within the security context of the hosting web site. With this privilege level, the code has the ability to read, modify and transmit any sensitive data and a variety of other information maintained by the browser on behalf of the user.

A user's browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code is normally written in HTML/JavaScript, but may also extend to Java, Flash, VBScript, ActiveX, or any other browser-supported technology. An attacker can bypass the client-side security mechanism that is normally imposed on the web content by modern browsers.

XSS Attack occurs in two phase:

• Inject scripting code into a web application

• Transfer sensitive information to the attacker.

It occurs when an attacker injects code into a vulnerable application to gather data from the user. The data can be gathered in the form of a hyperlink which contains malicious content within it. Let us consider

A vulnerable site under attack (For example, Un-sanitized data enters a web application, typically from a web request. Web pages are generated dynamically from this un-sanitized data. During Web page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.

Now an attacker can lure a victim client to click on a hyperlink supplied to him/her. The user is most likely to click on the link from another website, instant message, reading a web board, forum message or email message.

This link would cause the web browser of victim to access the vulnerable site ( and invoke the vulnerable script. As the script comes from a web page that was sent by the web server, the victim's web browser executes the malicious script in the context of the web server's domain.

This script could be malicious code that accesses the cookies the client browser has for the vulnerable site.

The malicious JavaScript can access:

• Permanent cookies (of maintained by the browser

• RAM cookies (of maintained by this instance of the browser, only when it is currently browsing

• Names of other windows opened for

• Any information that is accessible through the current DOM (from values, HTML code, etc.)

Type of XSS

There are three main kinds of XSS:

Type 1: Reflected XSS (or Non-Persistent)

Reflected XSS Vulnerabilities occurs when an attacker causes a victim to supply dangerous content to a vulnerable web application, which is then reflected back to the victim and executed by the web browser. The malicious content can be delivered as a parameter in a URL that is posted publicly or e-mailed to the victim. An attacker convinces a victim to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the victim, the content is executed by the victim's browser.

Type 2: Stored XSS (or Persistent)

The Stored XSS vulnerability is a more severe variant and it occurs when the attacker's malicious data is stored by the server and then permanently displayed to other users while regular browsing. The storage of data could involve a database, message forum, visitor log etc. In stored XSS, an attacker's malicious is rendered automatically without the need to lure the victim to third-party web sites or individually target victims.

Type 0: DOM-Based XSS

DOM-Based vulnerabilities occur when client performs the injection of XSS into the page. DOM-based XSS generally involves server-controlled, trusted script that is sent to the client, such as JavaScript that performs sanity checks on a form before the user submits it. DOM-based XSS is possible, if the server-supplied script processes user-supplied data and then injects it back into the web page (such as with dynamic HTML).

Detection of XSS vulnerability

Black Box:

Use the XSS Cheat Sheet [REF-14] or automated test-generation tools to launch a wide variety of attacks against your web application. The Cheat Sheet contains many subtle XSS variations that are specifically targeted against weak XSS defenses. Simple rules can be followed to prevent XSS using output escaping/ encoding properly. Both reflected and stored XSS can be addressed by performing the appropriate escaping on the server-side. While DOM-Based XSS can be addressed by applying rules on the client on un-sanitized data.

Dynamic Data Tainting [Nent07]:

In XSS, an attacker injects code into the output of the web application that is executed on the victim's web browser. Sensitive information is then collected and sent to the attacker. Dynamic data tainting prevents sending the sensitive data to the adversary without user's consent. In this mechanism, sensitive data is first marked (or tainted), and then when this tainted data is accessed by scripts running in the browser, it is dynamically tracked by the system. Different kinds of actions like logging, preventing transfer or stopping program with an error can be taken when this data is about to be transferred. Taint analysis is capable of tracking data dependencies. However it cannot be used for detection of all kind of control dependencies.

Static Data Tainting:

Static analysis ensures that all variables that could receive a new value on any program path within the tainted scope are tainted. The static analyzer looks at the data flow model and finds tainted data that is output back to the web browser through the web applications response. If output encoding is not used on the data then XSS is detected. Automated static accuracy for XSS is high.


Input Validation

Assume that all input is malicious, so use whitelist that consists of acceptable inputs confirming to specifications. Blacklist consisting of malicious or malformed inputs can also be used to reject the inputs.

Libraries and Firewalls

Use of libraries or frameworks to properly encode output like Microsoft's Anti-XSS library, Apache Wicket etc. can be used to avoid weakness. Use of firewall can also help.

Identify and reduce attack surface

Understand all areas where untrusted data can enter the software. For Example parameters, cookies, environment variables, query results, e-mails, filenames etc.

Output encoding

For every generated web page, use and specify a character encoding such as ISO-8859-1 or UTF-8

Severity of XSS

Attack Frequency


Remediation Cost


Ease of Detection


Attacker Awareness



Code execution, Security bypass

Real-World Attack Examples

Samy worm exploited XSS vulnerability and attacked MySpace [xss2]

In 2010, Orkut attacked by 'Bom Sabado' XSS worm. Infected users receive a scrap containing the words 'Bom Sabado'. [xss1]

Improper neutralization of special elements used in SQL commands (SQL Injection)

In database-driven web applications, many organizations store confidential and sensitive information such as customer records, order items or private documents. This information is made available over the network to authorized users. The authorization may be checked by verifying the user input against the database by generating SQL at runtime. If SQL syntax is not properly quoted in user-controllable inputs, then the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. This helps attacker to modify the query logic and bypass security checks or insert additional statements that modify the database or comment some important statements.


SQL Injection is a trick to inject SQL command/query as an input probably via web pages. It occurs when web based applications take parameters from user and generate a SQL query. An attacker intending to exploit the vulnerability looks for web pages that allow submitting data, i.e.: login page, search page, comments or feedback. SQL Injection is a subset of the unverified user input vulnerability and is caused by insufficient input validation i.e when data provided by the user is not properly validated and is included directly in a SQL query. An attacker exploits this vulnerability and creates specially crafted input strings that result in illegal queries to the database.

Attacker's intent:

• Extract, modify or add data to database

• Perform Denial of Service

• Bypass authentication

• Execute remote commands


Original SQL Query

queryString = "SELECT info FROM userTable WHERE" + "login='" + login + "' AND password=" + password;

• Insert additional queries to be executed by the database.

An attacker inputs password as "pwd; DELETE FROM userTable". Thus query executed at databse in case of unverified input would be:

queryString = "SELECT info FROM userTable WHERE login='name' AND password=pwd; DELETE FROM userTable"

• Create query that is always TRUE for the entries in database.

queryString = "SELECT info FROM userTable WHERE login='user' or 1=1 --' AND password="


Detection Techniques

Combined Static and dynamic Analysis (AMNESIA)

AMNESIA, a model-based technique combines static analysis and dynamic monitoring to detect SQL Injection. In static analysis, it builds models of different types of legal queries, an application can generate at each point of access to the database. While in dynamic phase, it intercepts all queries while on their way to database and checks each query against the statically built models. Violating queries are detected and prevented from executing on the database.

Intrusion Detection Systems

IDS is based on a machine learning technique that is trained using a set of typical application queries. Models of typical queries are built and at runtime application is monitored to identify queries that do not match the model. However this technique is dependent on quality of training set used.

Instruction Set Randomization

In this technique queries are created using randomized instructions instead of normal SQL keywords. A proxy filter intercepts queries to the database and de-randomizes the keywords. An attacker injects SQL code, which would not have been generated using the randomized instruction set. Thus it results in a syntactically incorrect query. However this technique has an overhead as it requires integration of a proxy for database in system.

Dynamic Tainting

In dynamic taint analysis, the propagation of un-sanitized input data is tracked to detect the vulnerability exploits. The primary drawback is identifying all sources of tainted user input in highly-modular Web applications and accurately propagating taint information is often a difficult task.

Prevention techniques

Defensive Coding practices [Halfond_abstracta]

Input type checking - A simple check of input parameters can prevent many attacks. For instance in case of numeric inputs, reject input that contains characters other than digits.

Encoding of Inputs - The meta-characters that trick the user input to be considered as SQL tokens can be prohibited. However doing so would restrict the non-malicious users to specify legal inputs that contain these characters. So use functions that encode the string where these meta-characters are encoded and interpreted by the database as normal characters. Use parameterized stored procedures for database access to ensure that input strings are not treated as executable statements.

Positive pattern matching - Establish input validation routines that identifies all forms of legal input.

Identification of all input sources - Identify and check all possible sources of input to application.

However, defensive coding is prone to human errors and is not efficient as automated techniques.

Black Box Testing

Identify all points in an application that can be used for SQL Injection. Based on list of patterns and attack techniques, build attacks on such points and monitor response to these attacks. Machine learning techniques are used to improve the attack methodology. However it cannot provide completeness guarantee.

Static Code Checkers (JDBC-Checker)

JDBC-Checker is a technique that statically checks the type correctness of dynamically-generated SQL queries.

Proxy Filters

It enforces input validation rules on the data flowing to a Web application. However this approach is human-based and requires knowing which data needs to be filtered, what patterns and filters to apply.


Attack Frequency


Remediation Cost


Ease of Detection


Attacker Awareness



Data Loss, Security Bypass

Real-World Attack Examples

On September 19th during the 2010 Swedish general election a voter inspired by an xkcd comic attempted a code injection by hand writing SQL commands as part of a write in vote.

On 8th November 2010 the British Royal Navy website was compromised using SQL injection.

Buffer Copy without checking Size of Input (Classic Buffer Overflow)

In Buffer Overflow, the program copies an input buffer to an output buffer, without verifying the size of input. If the size of input exceeds the output buffer, it leads to Buffer Overflow. This vulnerability accounts for more than 50% of reported vulnerabilities, has been the most common form of security vulnerability for past decades and it is still very hard to find/avoid.


In Buffer Overflow, actions like Read/Write are performed beyond the memory allocated to the buffer. The overwritten area could contain users or system data, users or system program code. Thus writing outside the bounds of a block of allocated memory can corrupt data, crash the program, or cause the execution of malicious code.

The following sample code demonstrates a simple buffer overflow, where the programmer creates a local copy of a buffer to perform some manipulations to the data.

void updateString(char* string){

char buf[24];

strcpy(buf, string);



In the above code, the programmer does not ensure that the size of data pointed by string will fit in the local buffer. It simply copies the data with strcpy() function. This may result in buffer overflow condition if an attacker exploits this weakness by influencing the contents of the string parameter.

Buffer Overflow and Web Applications

Attackers exploit buffer overflows vulnerability to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary malicious code - effectively taking over the machine.


Countermeasures [wag]

Choice of Programming Language

Use languages like Java, Haskell, or SML which prevent (classical) buffer overflows.

Secure Designing and Coding

Follow techniques to write secure programs that are less likely to contain buffer overflow vulnerabilities.

Replace unbounded copy functions like strcpy with analogous functions that support length arguments like strncpy.

Check buffer boundaries when accessing the buffer in a loop.

Use of safe libraries

Use Library-based defenses that have re-implemented unsafe functions and ensure that these functions can never exceed the buffer size. For example, Strsafe.h library from Microsoft, Libsafe library etc.

Non-Executable buffers

In this, the stack segment of victim program's address space is made non-executable; making it impossible for attackers to execute the code they inject into the victim program's input buffers. However an attacker could bypass this by injecting attack code into buffers allocated in heap or static data segments.

Array Bounds checking

All reads and writes to arrays need to be checked to ensure that they are within the range. Thus if arrays cannot be overflowed, then it cannot be used to corrupt adjacent program state. However the direct compiler approach imposes substantial costs. For example, Compaq C Compiler and Jones and Kelly's GCC patch.

Code pointer Integrity checking

It seeks to detect a corrupted code pointer before it is dereferenced. Thus even if an attacker succeeds in corrupting a code pointer, it will never be used because it will be detected before each use. However it does not perfectly solve the buffer overflow problem; overflows that affect program state components other than code pointers will still succeed.

Address Space layout randomization

ASLR is a feature which involves arranging position of key data areas in a process' address space. Randomization of the virtual memory addresses at which functions and variables can be found makes exploitation of a buffer overflow more difficult, but not impossible.

A source code tool analyzes the source code of a program and tries to determine whether it contains any unsafe code that could lead to buffer overflows. E.g. of such tools are Flawfinder, Viega's RATS, SPLINT and ITS4.


Attack Frequency


Remediation Cost


Ease of Detection


Attacker Awareness



Code Execution, Denial of Service, Data Loss

Real-World Attack Examples

In 2001, the Code Red worm exploited a buffer overflow in Microsoft's Internet Information Services (IIS) 5.0[bf1]

In 2003, the SQL Slammer worm compromised machines running Microsoft SQL Server 2000 [bf2]

In 2003, buffer overflows present in licensed Xbox games have been exploited to allow unlicensed software, including homebrew games, to run on the console without the need for hardware modifications, known as modchips.[bf3]

In 2008, buffer overflow attacks target Facebook and MySpace. [bf4]

Cross-Site Request Forgery

It is also known as Cross-Site Reference Forgery, One-Click attack, XSRF, or Session Riding. It is widely exploited web site vulnerability, where unauthorized commands are transmitted from the end user that the web site trusts. The web application cannot or does not perform verification that the request was intentionally provided by the user who submitted the request. It works by exploiting the trust that a site has in user's browser. This is in contrast to XSS where users trust for a particular web site is exploited.


An attacker exploits this weakness and tricks the client to make an unintentional request to the server which will be treated as authentic request. This can be done via a URL, image load, XMLHttpRequest, etc. that results in unintended code execution.

The attacker tricks the client to submit information to a web application. Let us consider an example where Alice wishes to transfer $1000 to Bob using The request generated would be:





Content-Length: 19;


However, an attacker Mallory notices that the same transfer is possible using URL parameters as follows:


Now Mallory exploits this vulnerability and constructs a URL which will transfer $100,000 from Alice's account to her account. She tricks Alice into submitting the request by sending an HTML email containing the following:

<ahref="">View my Pictures!</a>

If Alice is authenticated with the application while clicking the above link, then the attempt by Alice's browser to load the image will lead to transfer of amount to Mallory's account. Thus transaction would be authorized but without Alice's approval.

To hide this attack from Alice, Mallory uses a zero-byte image.

<img src="" width="1" height="1" border="0">


Manual Analysis

Use of tools and techniques requiring human analysis, such as penetration testing, threat modeling etc. can be used to detect the vulnerability. Black box analysis and gray box analysis can be used along with the understanding of business logic to find the weakness.

Automated Static Analysis

Detection of CSRF reliably using automated techniques is little difficult. It generates an unacceptable rates of false positives because the weakness is related to design and business rules.

Countermeasures [zel]

Avoid persistent sessions

Limit the lifetime of authentication cookies. Sites with special security needs like banks, often logs users off after a short duration of inactivity (for example: 15 mins)

Ensure application is free of XSRF, as it can bypass CSRF defenses using attacker-controlled script.

Use GET method properly

Allow GET request to only retrieve data and not modify any data on the server.

Use of unique Nonce

Use a server generated unique nonce to introduce challenge-response on requests. For each form nonce is placed into it and verified upon receipt of the form.

Require all POST requests to include pseudorandom value

When a user visits a web site, a cryptographically secure pseudorandom value can be generated and used as a cookie on the user's machine and as form value. When a POST request is sent to the site, the request should be considered only if form value and cookie value matches. When an attacker submits request on behalf of user, he cannot modify cookie values, per the same-origin policy. Thus the attack is restricted as the attacker will have to guess the pseudorandom value.

Checking the HTTP Referrer header

By ensuring the HTTP request have come from the original site means that the attacks from other sites will not function. However this may lead to issues with authentic user's browser that omit the Referrer header for privacy reasons.

Identify critical operations

When a user performs any critical operation, a separate confirmation request must be sent to ensure that the user intended to perform the operation.


Attack Frequency


Remediation Cost


Ease of Detection


Attacker Awareness



Data loss, Code execution

Real-World Attack Examples

On May 19, 2010 Facebook scrambles to close CSRF hole that exposes private data even when they were designated as private. [csrf1]

On Sep 27, 2010 Twitter was hit by WTF worm where links in micro-blogging messages contained hidden JavaScript code that exploited CSRF weakness. [csrf2]

Improper Access Control (Authorization)

Applications, in general, should allow access to only those who are permitted. This means an unauthorized user should be prevented from invoking functionality when they don't have permissions. This is accomplished by enforcing access control checks at appropriate boundaries or method calls. Improper Access Control is a vulnerability, where the software does not perform or incorrectly performs access control checks. An attacker can exploit this weakness and is able to access data, view sensitive files or perform actions that they should not be allowed to perform.


Automated Static Analysis:

Static analysis models all the possible paths of execution of a program without executing it. An automated tool may be used to analyze configuration files or authorization libraries. However these tools face the problem detecting custom authorization schemes. It is possible that a particular resource does not require authorization check; an automated technique may report false positives due to lack of authorization.

Automated Dynamic Analysis

Dynamic Analysis technique tests a component, initially with no permissions. An authorization failure occurs if the component tries to access a restricted resource. Each failure is logged and accordingly access control policy is updated. However manual analysis is required to determine if the lack of authorization violates business logic.

Manual Analysis

Using tools and techniques that require human analysis, such as penetration testing, threat modeling and interactive tools allows the tester to record, modify active session and evaluate the correctness of authorization schemes. However manual efforts face problem of achieving full code coverage within limited time constraints.


Access Control List (ACL):

Use of ACL, which is a list of permissions attached to an object. It specifies which users or processes have access to the object and also what operations can be performed on the object.


Divide the application into different areas of administration and accordingly create roles. These roles will be mapped with data and functionality. Thus RBAC can be used to enforce roles at various boundaries. However this does not provide protection against users attacking others with the same role.

Perform access control checks related to business logic

Authorization Framework

Use of authorization framework like JAAS authorization framework does not allow or makes it easier to avoid this weakness.

For Web Applications

Enforcing access control mechanism at the server side, so that users cannot access any unauthorized functionality. For example, ensure that pages containing sensitive information are not cached.


Attack Frequency


Remediation Cost

Low to Medium

Ease of Detection


Attacker Awareness



Security Bypass

Unrestricted Upload of file with dangerous type

Many attacks follow the 2 step path where the first step is to send malicious code to the system to be attacked and then execute the code. Uploading files pose a significant risk to applications. An attacker exploits the weakness of unrestricted upload of file and accomplishes the first step.

The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system, forwarding attacks to backend systems, and simple defacement. It depends on what the application does with the uploaded file, including where it is stored.


The weakness occurs when software allows attacker to upload or transfer files that can be processed automatically within the system. Consider the following example where there is no check of the file being uploaded.

// Define the target location where the picture being

// uploaded is going to be saved.

$target = "pictures/" . basename($_FILES['uploadedfile']['name']);

// Move the uploaded file to the new location.

if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target))


echo "The picture has been successfully uploaded.";




echo "There was an error uploading the picture, please try again.";


An attacker could upload a file with the name 'malicious.php'. As the filename ends in ".php", it will be executed by the web server. Thus this allows the attacker to execute malicious arbitrary commands, once the file has been installed.

Countermeasures [ULL]

Generate new file name

Instead of using user-supplied filename for an uploaded file, generate new file name.

Store file outside of the root document.

This way, an attacker will not be able to access the file directly and it provides fine grained access control

Input Validation

Assuming that all input is malicious, use an input validation strategy like whitelist i.e. acceptable inputs that strictly conform to specifications. All relevant properties must be considered like length, type of input, range of acceptable values, syntax, missing or extra inputs and conformance to business rules.

Define a very limited set of allowable extensions and only generate filenames that end in these extensions.

Keep tight control of permissions

An uploaded file might only need read/write permission and not execute permissions.

Run your code using the lowest privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.


Attack Frequency


Remediation Cost


Ease of Detection


Attacker Awareness



Code execution

List of Programming errors

In this report, I have analyzed in detail few software vulnerabilities which are caused by programming errors or software bugs. The table below gives a list of these.




Improper Neutralization of Input During Web Page Generation


Code execution, Security bypass

Improper Neutralization of Special Elements used in an SQL Command

SQL- Injection

Data loss, Security bypass

Buffer Copy without Checking Size of Input

Classic Buffer Overflow

Code execution, Denial of service, Data loss

Cross-Site Request Forgery


Data loss, Code execution

Improper Access Control


Security bypass

Unrestricted Upload of File with Dangerous Type

Code execution

Having a detailed list of programming errors is beneficial to people belonging to different categories.

Programmers: The list of programming errors can be used as a checklist of reminders. While developing or implementing a secure software solution, these vulnerabilities should be considered as they are becoming more prevalent. The detection and prevention mechanisms included in the list gives the programmer an understanding of effective countermeasure practices. Thus avoiding or reducing the weakness in the system.

Software Testers: The list of programming errors helps them to integrate the knowledge of weakness into their tests. Thus they create an effective set of tests which would help in eliminating or reducing the existence of the weakness in the software system.

Software Project Managers: The list of programming errors acts as an early step to achieve the software security. It gives the managers a way to analyze the probable weakness and fix them in the early stages of development lifecycle model.

Software Customers: With a list of programming errors in the hand, they come to know about the most prevalent and dangerous vulnerabilities existing in the market. These people can then demand the software vendors to provide secure products.

Academic Institutions: This list can act as guidance checklist to teach principles, concepts to the budding programmers.