Canonicalization

Canonicalization mistakes are caused when your application makes a security decision based on a name (such as a filename, a directory name, or a URL) and more than one representation of the resource name exists, which can lead to the security check being bypassed.

Test Cases

1. For all vulnerable API, attempt to read/write files using the following variations: “FileName::$DATA” and “File~Name.txt”

2. Attempt to read/write a file by using parent paths (i.e. /../../autoexec.bat).

3. Use hexadecimal escape codes (i.e. %20, the space character) to represent characters in an attempt to read/write a file.

4. Use UTF-8 variable-width encoding to read/write a file. UTF-8 variable encoding allows one character to potentially map to multiple-byte representations, and thus can be problematic. For instance, use %c0%af (which stands for //) to read/write a file.

5. Use UCS-2 Unicode encoding and double encoding

6. Use HTML escape codes (i.e. < and >) to read/write a file from a web page (if applicable).

7. Pass a really long file name in an attempt to read/write a file.

Analyze the data management layer for code that inputs file paths and explore for canonicalization mistakes

Read more

Cross site scripting - XSS

Cross site scripting occurs when a web application gathers raw malicious data from a user. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website.

Test Cases

1. Set every field, header, and parameter for all web services to the following script: “><script>alert(window.location);</script>.” Also, add one carriage return to the input at the beginning to see if the methods are able to scan multiple lines of the input. Call each web method through a web page. If a dialog appears in the browser, then there is a possible cross-site scripting bug.

2. On the runtime site, create a basket. Set the basket name to be “<script>alert(document.cookie)</script>.” Create a web page that calls AcceptBasket on the orders web service to obtain the created basket. If the alert window appears, then there may be a possible cross-site scripting vulnerability.

3. In the marketing system, create a promo code by setting the name to “<script>alert(document.cookie)</script>.” On the runtime, run the pipeline to obtain the promo code record in the site. Display the name of the record.

4. In the catalog system, create a product and set the name to “<script>alert(document.cookie)</script>.” On the runtime, display the product.

5. On the runtime, create a profile by setting all properties to “<script>alert(document.cookie)</script>.” Create an order address using this profile and submit the order. Obtain the profile using the profile web service using a web browser.

Read more

SQL Injection

SQL injection is a vulnerability in which user input is used to make an application run SQL code that was not intended. If the application is creating SQL strings naively on the fly and then running them, it's straightforward to create some real surprises.

Most of the subsystem API is not acceptable to SQL injection attacks because dynamic SQL is not created. However, the management search API, included in marketing, orders, profiles, and catalog, should be further investigated anyways for possible SQL injection vulnerabilities. Search API’s are also very susceptible.

Test Cases

1. Some of the web services use XML to specify search clause using the search clause builder API. Use SQL Profiler to observe how the queries are created, and adjust the user input as appropriate to look for possible SQL injection vulnerabilities.

2. Investigate development code and look for places where SQL is dynamically generated. There should be no code dynamically building SQL.

3. Pass the % character as user input to see if it is possible to retrieve additional data. The % character may expose possible information disclosure threats which can lead to possible elevation of privilege threats. Also test using the “[“ and “_” characters.

4. On the runtime, apply SQL injection tests component keys.

Read more

End to End Security testing

End-to-end security testing, also referred to as end-to-end security penetration testing, describes security testing with all the application components integrated together. Security penetration testing addresses how hackers would try to break into the system. This testing includes:

· Addressing the security issues that appear when components are integrated and end-2-end scenarios is targeted. This testing is focused on integration points, and looking for vulnerabilities created by incorrect assumptions made about each other.

· Accessing the attack surface and identifying all potential points of direct entry into the application.

· Fuzz testing and fault injection on end-2-end scenarios using smartly crafted bad input, deliberately causing various dependencies to fail, disappear, lie, duplicate etc.

· Denial of service attacks: targeting scenarios which may cause exhaustion of system resources (like CPU, memory, network, kernel objects) and custom resources (like shopping baskets). Sometimes good algorithms fall on their faces when fed “exactly incorrect” data. We will look out for these too.

· Client server issues: session hijacking, spoofing, replay of authenticators.

· Man-in-the-middle attacks, eavesdropping, and data tampering

· Input validation on integration scenarios – SQL injection, cross-site scripting, and name canonicalization tests.

· Verifying that the application’s default configuration is the most secure.

· Verifying that the principle of least privilege and separation of privilege is adhered to in the end-to-end scenario. We will also consider social engineering issues and their potential impact.

· Review all uses of cryptography (algorithms, key management).

Read more

Secure deployment testing

1    Verifying that the deployment process is functionally correct
2    Making sure that the secure deployment documentation is correct and provides best security practices.
3    Validating the permissions and rights required for the different servers and user roles, business users, visitors, editors, publishers, and administrators. This includes:
    Secure ACLs on configuration files, registry keys, temporary files, named pipes, murexes and all other securable objects.
    Correct configuration of database roles, stored procedures, and service/application accounts
    Looking for components running by default when they shouldn’t be
    Investigating network ports. Verify IDL files for correctness.
    Sensitive data is not exposed in logs, event viewer, remote error messages, traces, and registry keys
    Ensure failures are graceful, default system state is access denied (instead of all access) and no critical information is leaked out to client/remote caller.
4    Verify the lockdown templates/settings representing common “server roles” that the product is used in
5    Verifying that the least privilege principle is followed.
6    Verify that the separation of privilege principle is followed.

Read more

Component Level Security Testing

Component level security testing, also referred to as feature area level security testing, describes security testing isolated by the feature area

Threat Model
    Test the threat model; each threat bug which is fixed must have a test verifying the mitigation. Ensure there is a test case for each threat (automated or manual).
    Gain a thorough understanding of threat model for your component and the security model for the product.

Secure Default Configuration
    Create test cases that ensure that default configuration is secure.
    Think about the ACLs required on various artifacts
    Think about the application, service, and database roles required
    Validate that sensitive error messages are secure

Authorization Manager
    Verify that the roles are functionally correct.
    Call each sensitive API for each out-of-box role
    Create customized roles for the sensitive API, focusing on the most powerful permissions
    Think of ways you can bypass Authorization manager (AzMan) checks

Input Validation
    Buffer overflows
    SQL Injection
    Cross-site Scripting
    Filename Canonicalization (all paths (XPath queries. Registry. Etc.) must be properly handled)
    Input Length (as appropriate)

Minimal Privilege
    Attempt to run tests in the least privilege configuration
    Use a non-admin account on dev machine while running tests
    Verify that various tasks are not feasible if an account with lesser privilege than the minimum specified is used.

Concurrency
    Determine if it is possible to exploit race conditions
    Think about caching and timing related issues.
    Test security relevant operations alternately expecting failure & success using 1 thread, and using multiple threads
    Time of check and time of use issues; see if missing atomicity can be exploited to bypass security enforcement.

Fuzz Testing
    Pass garbage into inputs
    Pass partially correct data into inputs, but containing garbage values (develop file and network fuzzers for all protocols and file formats)

Code Access Security
    New type of security in the .Net Framework
    Controls application authorization
    Concepts: Evidence, Permission Sets, and Code Groups
    Verify that Internet based client-side applications do not need full trust

Read more