The core function of the Analysis & Modeling is to identify security threats, while facilitating the process of defining application framework with security strategy. Even if you are not a security subject-matter expert, you now have the ability to consistently and objectively identify threats to your software application.
Creating a secure application framework model is a three-phase process. First, you define your application context. Second, you model your threats on top of your application context. Third, you measure the risk that is associated with each threat. Once you have completed these phases, you can assimilate your application framework.
The application framework model has the capability to assimilate and build security artifacts such as access control matrices, data flow and trust flow.
When it comes to developing an application, writing secure code should be the aim of every developer, since much vulnerability is caused by bad coding practices, sometimes the OS or the third party component that we’re using could have vulnerabilities, and through developers not being aware of the nature of certain types of threats. In this document we investigate some common types of vulnerabilities that we expose ourselves to when not treating the client with sufficient caution.
We look at various types of attacks that might be launched if we do not protect ourselves from the client, and how we test the attacks and code the application with the corresponding technology techniques.
By designing the application for the various types of attacks listed in this document, we can guarantee that our web application is secure from the common attacks.
What is application context?
In order to understand your application context, you must understand the individual elements that, together, create it. Defining the various elements of your application individually enables each element to be analyzed and coupled together to define an application context. This makes it possible to identify potential threats, and then systematically build an effective security strategy.
How is this done?
To define your application context, it is necessary to first define your application requirements, and then define your application architecture. The application requirements consist of business objectives, user roles, data, and use cases, all of which are defined by business owners. The application architecture consists of components, service roles, external dependencies, and calls, and is defined by application architects.
Define Application Requirements
Application requirements consist of your business objectives, user roles, data and use cases. Before you can begin to define the application requirements, you must first define the scope of the application and identify various threats in the defined scope.
Business Objectives
Business objectives are your goals - that is, the reason for creating your software application. Applications are developed to fulfill specific business needs, or to solve some specific business problem. These needs or problems are your objectives that need to be fulfilled by your application in order to benefit your business.
User Roles
Roles define the trusts of your software application, and they are primarily used to make authorization decisions. Any user who will be interacting with the application must be assigned a user role.
Data
Data defines the information type that is maintained or processed by your software application. Optionally, data types can be broken down into specific elements that, together, make up that specific data.
Example: User profile data consists of the following elements: salutation, user's first name, user's middle initial, user's last name, street address, and so on.
In order to identify the data types within a software application, data elements are grouped into logical sets, which can then be classified.
Application Use Cases
Once you have defined your roles, data and access control, you must define use cases that, at the very least, define the scenarios that are used to realize specific subsets of the defined access control.
A Use Case is an ordered sequence of actions that are used to realize an effect. This effect, known as the Net Data Effect, is a specific subset of the access control matrix that is realized at the end of the use case.
Example: Reading product information, or updating credit card records.
When you run the data access control matrix, you will see all the access controls that are maintained by your application. These access controls are realized with use cases.
Example: Suppose you have a use case called Creating Customer Account. If you define a user role with the access control to create credit card information, your use case must support this.
Use cases can be analyzed, to determine what elements are required in order to accomplish them, as well as how they interact with other objects.
Example: A user role, website component, and database component are some of the elements required for the creating customer account use case.
In short, a use case defines what needs to happen.
Define Application Architecture
Your application architecture is comprised of your components, service roles, external dependencies and calls. You begin defining your application architecture by defining your components.
- Components
Example: A database in which a user's credit card information is stored, web services, websites, and thick clients.
- Service Roles
Example: Website roles and database roles for your website and database components, respectively.
- External Dependencies
Example: .NET Passport is an external dependency of www.hotmail.com.
- Calls
Recall that use cases define the set of actions or features that need to be supported by your application, and these allotted actions can be executed by specific roles in order to achieve a net data effect. Put simply, use cases define what needs to happen, and calls define how it happens.
Model
Application modeling is meant to be an iterative process in which the application evolves through the many stages that information is consolidated from different members of your application team.
- Identifying Threats
- Primary Threat Factors
- Confidentiality Threat
- Integrity Threat
There are three primary threat factors that fall into the integrity category. The primary factors are the violation of access control, business rule(s), or data integrity.
- Violation of access control Example: In your access control, you set permissions that allow administrators to create, edit, and delete product pricing information, while you set permissions that allow registered users to read product information. If your access control was violated and registered users were allowed to edit product pricing information, it would be possible for them to set all pricing to zero. This would be an enormous threat to your business.
- Violation of business ruleThe violation of business rule is something to consider that may be outside the realm of access control and data integrity.
Example: A banking transaction use case is made up of two calls, a withdrawal and a deposit. The business rule is that a user cannot make a withdraw without first making a deposit (i.e. there needs to be money in the users account in order for them to take any out). If a user was allowed to withdrawal money from a bank without having to make a deposit first, banks would surely be depleted quickly.
Note: If you check Violation of business rule as a primary threat factor, you must supply the business rule. - Violation of data integrityExample 1: Consider a user's credit card information. It is crucial that the correct credit card number is paired with its rightful owner (user).
Example 2: Consider a case where an attack is able to compromise your application and modify the price of all your products that you sell to $1. This attack violates your data integrity by compromising your product information and pricing.
- Availability Threat There are two primary threat factors that fall into the availability category. The compromise could happen through the ineffective execution of the action or due to performance degradation.
- Unavailability
Example: When a website is required to be available 99.9% of the time or a bank that needs to be open during their advertised business hours, the unavailability of either could cause significant business impacts.
Note: If you check Unavailability as a primary threat factor, you must supply a definition of the availability condition. - Performance degradation
Example: If an e-commerce site takes more than 5 seconds to respond to a request, this may be considered a threat, especially if this ineffective execution will result in a loss of potential business.
Note: If you check Performance degradation as a primary threat factor, you must supply a definition of the performance requirement.
After you have classified your threats, your next step is to define how you will respond to them.
- Unavailability
The process of measuring risk is very subjective. Because of this subjectivity, once the Threat Analysis & Modeling has modeled your application context and identified threats, you should measure the probability and impact of each threat in relation to your own business needs.
In the measure phase, you will attempt to quantify your threats. This is achieved through quantifying the risk associated with each threat.
Note: Although risk measurement is subjective, as long as the user stays consistent in the measurement, the user is provided with a priority that can be used to appropriately allocate resources in an effort to guard against the realization of threats.
Risk Response
Along with measuring the risk associated with each threat, your threat model should also facilitate and document the responses to those identified risks. There are four responses one can have towards an identified risk. You can choose to accept, avoid, reduce, or transfer the risk.
- Accept: Choosing to accept a risk would be appropriate when the business supporting the software application takes full ownership of that risk, and all that it entails in terms of the negative business impact.
- Avoid: Risk is avoided when all supporting features for the underlying factors are removed. If, for example, the threat is concerned with the unavailability of some action, then that action needs to be removed.
- Reduce: Risk is reduced by applying countermeasures which lessen either the impact or the probability of the threat.
- Transfer: Risk is transferred when the underlying action is transferred to an external dependency. Risk is also transferred when the risk inherent in the action is illustrated to the user and the user accepts that risk in order to use that feature.
Overview
An attack library is a collection of attack types along with their relevant vulnerabilities and proposed countermeasures to those vulnerabilities. Attack libraries enable software application teams to define and adopt secure engineering techniques, gain the information necessary to detect security concerns, and create relevant security test cases.
Attack libraries provide a way to define, with absolutely minimal permission, the relationship between the exploit (attack), the cause (vulnerability), and the fix (countermeasure). The attack library helps ensure that various development teams understand the security assumptions and dependencies of your application.
Note: Attack libraries are meant to be created by security subject-matter experts and consumed in the process of threat modeling.
Buffer Overflow
A buffer overrun occurs when a buffer declared on the stack is overwritten by copying data larger than the buffer. Variables declared on the stack are located next to the return address for the function’s caller. The usual culprit is unchecked user input passed to a function such as strcpy, and the result is that the return address for the function gets overwritten by an address chosen by the attacker. In a normal attack, the attacker can get a program with a buffer overrun to do something he considers useful, such as binding a command shell to the port of their choice.
How to Test:
The most common way to detect potential Buffer Overflow attacks is listed below:
- Identify all entry points of the application that collect user input via text boxes, command line parameters etc.
- Provide exceedingly long input via all entry points [For e.g AAAAAAAAA….] and submit the request.
- If the long input that you provided results in buffer overflow attack, you would receive an exception message.
Canonicalization
Different forms of input that resolve to the same standard name (the canonical name), is referred to as canonicalization. Code is particularly susceptible to canonicalization issues if it makes any decisions based on the name of a resource that is passed to the program as input. Files, paths, and URLs are resource types that are vulnerable to canonicalization because in each case there are many different ways to represent the same name.
How to Test:
The most common way to detect the potential of a Canonicalization attack:
- Identify entry points that collect user input for file paths, url’s in text boxes, query string parameters, etc.
- Try to enter the following strings which could represent the same file and submit the request. (Valid file name is somefile.dat) c:\temp\subdir\...\somefile.dat, c:\ temp\ somefile.dat, ..\somefile.dat, C%3A%5Ctemp%5Csubdir%5C%2E%2E%5Csomefile.dat.
- If the application accepts the above mentioned different forms of file names application is vulnerable to Canonicalization.
- Please note that the exception/error messages/control flow/program flow may be logged therefore simply checking the UI will not be sufficient.
Cross-site script (XSS) attacks can occur whenever a users input is echoed back to the browser without adequate validation, sanitization or encoding, enabling an attacker to supply input which the victim's browser interprets as client-side script originating from the vulnerable application.
The XSS attacks could be categorized as persistent or non-persistent.
In the "direct" or "persistent" scenario, the attacker posts malicious data to the web server which is stored and later replayed to the victim. In the "indirect" or "non-persistent" scenario, the attacker supplies the victim with a URL or HTML form which contains malicious script. The victim's browser passes the malicious script to the vulnerable site, which replays it to the victim's browser. In both cases, the script is executed in the trust context of the vulnerable site.
Typical XSS exploits target the victim's cookies, transmitting them to the attacker so that the attacker can impersonate the victim on the vulnerable site. In general, XSS exploits enable attackers to take arbitrary actions on the vulnerable site on the victim's behalf. In the worst-case scenario, an attacker can use XSS to seize remote control of the victim's computer
How to Test:
The most common way to detect the potential of a XSS attack:
- Identify entry points that collect user input such as Form inputs [e.g text boxes], query string parameters, etc.
- Check if the user input is echoed back to the browser.
- Insert “” as an input and submit the request.
- If this pops up an alert box saying “XSS” attack was successful.
- Depending on the context of the output this payload might need more tweaking. Do a View Source to find where & how the input was echoed back.
- Presence of the input without encoding in the source indicates XSS vulnerability.
Cryptanalysis is the science of cracking codes, decoding secrets, violating authentication schemes and breaking cryptographic protocols. It is also the science devoted to finding and correcting weaknesses in cryptographic algorithms. It is understood within the field of Cryptology that an algorithm should not rely on its secrecy. An algorithm should always be made available for public scrutiny. It is this scrutiny that will make it a well trusted algorithm. Inevitably, vulnerability in the algorithm will be exploited.
How to Test:
The most common way to detect the potential of a Cryptanalysis attack:
- Check for the algorithm which is used for encryption in the application.
- Check for any custom algorithms are being used in the application.
- Check the bit length of Keys that are used for encryption.
- Check for how the Keys are secured and maintained.
A Denial of Service (DoS) attack is an incident in which a user or organization is deprived of the services of a resource they would normally expect to have. Typically, the loss of service is disruption of services like e-mail, directory services etc. In the worst cases, for example, a Web site accessed by millions of people can occasionally be forced to temporarily cease operation. A denial of service attack can also destroy assets in a computer system. Although usually intentional and malicious, a denial of service attack can sometimes happen accidentally. A denial of service attack is a type of information theft which will cost organization’s time & money.
How to Test:
The most common way to detect the potential of a Denial of Service attack:
- Identify entry points that accept user input (such as file upload, accepting user comments etc).
- Insert huge/unexpected input as an input and submit the request.
- Repeat step 3 until resources (memory, CPU Utilization) get exhausted.
- Identify whether application behaved in an unexpected way.
- Also identify whether an exception/error message was generated relating to request (e.g., Page cannot be displayed).
Forceful Browsing
With the forceful browsing attack, the attacker gains access to a restricted page within a Web application by supplying a URL directly (forcing the URL) instead of accessing it by following links from other pages in the application. The intended workflow to get to the restricted page is through another page which authorizes the user to access the target page. This attack also allows attacker to gain access to resources to which no direct links exist.
How to Test:
The most common way to detect the potential of a forceful browsing attack:
- Identify vulnerable Files, Hidden Un – Referenced Files, Back-Up Files / Temp Files etc.
- If user can be able to access the above files, then forceful browsing is achieved.
A common function used to output data are the printf family of functions. When a programmer calls these functions with user input without explicitly specifying a format string several threats are created. By manipulating input to these functions, attackers can read and write to generally arbitrary regions of memory and create several unfavorable application conditions such as arbitrary code execution.
How to Test:
The most common way to detect the potential of a format string attack:
- Identify code instances were the printf classes of functions are called without providing explicit format strings.
Attacker Replays old HTTP requests to the web server by monitoring the HTTP packets from USER-Server traffic. The web server will not be able to differentiate the request sent by an attacker. With HTTP Replay attack, the attacker captures the user's authentication cookie using monitoring software and replays it to the application to gain access under a false identity.
How to Test:
The most common way to detect the potential of a HTTP Replay attack:
- User access valid site (ex: www.abcbank.com)
- User submits a request. (ex: for money transfer)
- Attacker tries to capture the HTTP packet using any sniffing tool. (ex:Netmon)
- Attacker replays the packet and tries to access the actual site through this information.
- If actual site consumes the request & process it then it is prone to HTTP replay attacks.
Integer arithmetic’s are frequently used in computer programs on all types of systems.
The register width of the processor determines the native type of integer and the range of operand values. Typical binary sizes for integers include 8 bits, 16 bits, 32 bits (the most common width as of 2005), 64 bits, and 128 bits. Since a math operation may give a result larger than the available register width, an error condition may result.
On systems where the result of an arithmetic operation is simply stored, and no error is returned (this is the general case), it may not be possible for the software to determine that the value stored is erroneous. If an integer value is used to specify the location of other code or variable values in memory, the resulting pointer error may be exploited to create a buffer overflow condition or
to write and execute arbitrary (and possibly harmful) code to the resulting (and unexpected) position.
How to Test:
Scan code performing arithmetic operations.
- LDAP Injection - The Lightweight Directory Access Protocol (LDAP) API provides a mechanism for connecting to, searching, and modifying internet directories. A LDAP (Lightweight Directory Access Protocol) injection attack exploits vulnerabilities in input validation to run arbitrary LDAP statements against information directories. It can occur when your application uses input to construct dynamic LDAP statements to access directory services. Using the LDAP injection attack, the attacker can execute arbitrary statements against the directory services.
The most common way to detect the potential of a LDAP Injection attack:
- Identify entry points that collect user input such as text boxes, query string parameters, etc.
- Insert any character (‘(‘, ‘|’, ‘&’) as an input and submit the request.
- Identify whether an exception/error message was generated relating to LDAP (e.g., Page cannot be displayed).
- Man in the Middle Attack -A man in the middle attack occurs when the attacker intercepts messages sent between the sender and receiver. The attacker then changes message and sends it to the original recipient. The receiver has no way to identify if the message is from the actual sender. Here the attacker is spoofing the identity of both sender and receiver.
Any network request involving client-server communication is subject to man in the middle attacks. These include
- Web requests
- Distributed Component Object Model (DCOM) requests
- Calls to remote components
- Web services
- Network Eavesdropping
Network Eavesdropping is the act of monitoring network traffic for data, such as clear-text passwords or configuration information. With a simple packet sniffer, all plaintext traffic can be read easily. Also, lightweight hashing algorithms can be cracked and the payload that was thought to be safe can be deciphered.
How to Test:
The most common way to detect the potential of a Network Eavesdropping attack:
- Install any sniffing tool (e.g. Network Monitor, packetyzer, etc…) and observe the communication channel between the source and destination server. Check whether packets captured in the sniffing tools shows sensitive or high business impact data (like password, connection strings, bank a/c numbers & cc number etc.) in clear text.
One-click attack has been called by several names within the security community. It is can also be called -CSRF, Page bounce, and Session Riding attack. A one-click attack is, when a third-party attacker causes an action of their choice to be taken on a victim’s behalf at the vulnerable site. In a one-click attack, the attacker must entice the victim into clicking a link or viewing a web page that was generated by the attacker.
The attacker lures an unsuspecting user into browsing to the page, and then causes the page to be sent to the server where the view state is valid. The server has no way of knowing that the view state originated from the attacker.
Consider this example, where vulnerable.com authenticates the user and subsequently maintains state using session cookies. Vulnerable.com has an administration page, /admin/deluser.asp. This page expects a query with the ID number of the user to delete as a parameter to the query.
How to Test:
The most common way to detect the potential of a one-click attack:
- Identify the areas in the application which are performing critical operations (for ex. Deleting user, transferring funds etc.)
- Verify if the application is re-authenticating the user at these points or not.
- Verify if the application design checks whether these requests are being placed by the genuine users or not.
- Create a duplicate pre-filled form and try to post it to same vulnerable site in the background to launch the attack.
A Password Brute Force attack is an automated process of trial and error used to guess a user’s credentials until successfully found. Brute Force Attack is performed using an educated guess to attempt to narrow down the key value. For example, someone could begin guessing a password by using a person’s first and last names, then spouse’s name, then pet’s name, and continuing with other common strings for passwords.
How to Test:
The most common way to detect the potential of a Password Brute Force attack:
- Identify an entry point that collects user credentials as input such as text boxes, query string parameters, etc.
- Input guessed credentials; submit the request for n number of time until you succeed.[Note : this can also be automated via brute force tools]
Repudiation is the ability of users (legitimate or otherwise) to deny that they performed specific actions or transactions. Without adequate auditing/Logging, repudiation attacks are difficult to prove. Repudiation attack allows an attacker to carry out a transaction and leave no evidence that the transaction was performed by the attacker.
How to Test:
- Check if the application is configured with anonymous authentication.
- Check if the application implements a poor authorization model.
- Check if application lacks logging or maintains ineffective logging.
HTTP Response Splitting techniques provide attackers with new attack vectors for defacing website content and end-users. User controllable input parameters placed into HTTP response headers in the absence of adequate data validation creates the potential for HTTP Response Splitting attacks. HTTP Response Splitting attacks allow for both local and remote cache poisoning which can result in arbitrary content being displayed to website visitors. This type of attack is possible when server script code embeds user data in HTTP response headers in the absence of any data validation.
How to Test:
The most common way to detect the potential of a Response Splitting attack:
- Identify all the points where user controlled data is placed in to HTTP Response headers.
- Try to send this payload in the input which supposedly is being placed in the response header by the application.
- If you get back page with Hacked! displayed, then application is vulnerable to response splitting attacks.
Session hijacking is the act of taking control of a user session after successfully obtaining or generating an authentication session ID. In session hijacking an attacker using a captured, brute forced or reverse-engineered session ID seizes control of a legitimate user's Web application session while that session is still in progress. The severity of the damage incurred depends on what's stored in the session state.
How to Test:
The most common ways to detect the Session Hijacking attack are:
- The communication channel is over HTTP
- Site Vulnerable to XSS attack
- Session IDs in URL
- No authorization check in code.
- Use of persistent cookies.
A SQL injection attack exploits vulnerabilities in input validation to run arbitrary commands in the database. It can occur when your application uses input to construct dynamic SQL statements to access the database. It can also occur if your code uses stored procedures that are passed strings that contain raw user input. Using the SQL injection attack, the attacker can execute arbitrary commands in the database. The issue is magnified if the application uses an over-privileged account to connect to the database. In this instance it is possible to use the database server to run operating system commands and potentially compromise other servers, in addition to being able to retrieve, manipulate, and destroy data.
How to Test:
The most common way to detect the potential of a SQL Injection attack:
- Identify entry points that collect user input such as text boxes, query string parameters, etc.
- Insert the single quote character (‘) as an input and submit the request.
- Identify whether an exception/error message was generated relating to SQL.
XML Injection
An XML injection attack exploits vulnerabilities in input validation to create a new node to alter the program decision/flow. It can also be used to insert malicious characters into XML and break functionality. It occurs when the application uses input from the user to construct dynamic XML to send it to the backend database or does transformation to display it back to the user.
How to Test:
The most common way to detect the potential of a XML Injection attack:
- Identify entry points that collect user input such as form fields, query string parameters, etc.
- Identify the XML attributes that may be injected in XML, causing an unexpected behavior (such as exceptions while parsing the generated file, reference to external entities, tampering data, etc)
- If you use XML functions, such as constructing XML string or use XSLT template expansion with the tainted data, you are most likely vulnerable.
Secure Web Application Modeling discipline advocates the use of proactive, structured threat management for software development projects. The Secure Web Application Modeling is a process of six logical steps (identification, analysis, planning, tracking, controlling, and learning) through which a project team should cycle continuously during the project life cycle. The learning step is used to communicate Secure Web application Development lessons learned and feedback on enterprise-level application threat resources to an enterprise-wide threat risk knowledge base.
References
Following are the web references:
0 comments:
Post a Comment