Skip to main content

Insecure Processing of Data

This category covers the following issues:

Fixing Cross-Site Scripting​

About XSS

What is Cross-Site Scripting?​

Cross-site scripting (XSS) is a type of security vulnerability that allows attackers to inject malicious code into web pages viewed by other users. This occurs when an application fails to properly sanitize user input and injects untrusted data into a web page without validating or encoding it.

XSS attacks can occur in different forms, such as reflected, stored, or DOM-based, and can affect various types of web applications, including social media, e-commerce, and online banking sites.

Attackers can use various techniques, such as phishing emails, web forms, or malicious links, to trick users into visiting or interacting with web pages that contain malicious code.

Check out this video for a high-level explanation:

What is the impact of Cross-Site Scripting?​

Cross-site scripting (XSS) can lead to various security threats and risks, such as:

  • Information theft: XSS attacks can steal sensitive information, such as login credentials, credit card details, or other personally identifiable information, by injecting malicious code that collects and transmits user data to attackers.
  • Account hijacking: XSS attacks can hijack user sessions by injecting malicious code that takes over user sessions, allowing attackers to perform unauthorized actions on the website or gain access to user accounts.
  • Data tampering: XSS attacks can modify or delete data on a website by injecting malicious code that alters the content of web pages, leading to data tampering, data corruption, or other types of malicious activities.
  • Malware distribution: XSS attacks can distribute malware by injecting malicious code that downloads and installs malicious software on the user's computer, leading to malware infections or other types of cyber attacks.

Overall, XSS attacks can compromise the confidentiality, integrity, and availability of data, leading to a range of security threats and risks.

How to prevent Cross-Site Scripting?​

To prevent XSS vulnerabilities, you can take the following steps:

  • Input validation and sanitization: Ensure that all user input is validated and sanitized before being used to generate web pages or manipulate other data. Input validation should include validating the data type, length, and format, and filtering out any special characters that could be used to inject malicious code.
  • Output encoding: Encode all output to protect against XSS attacks. Use output encoding techniques such as HTML entity encoding, URL encoding, and JavaScript encoding to encode user input and output to the browser.
  • Use security headers: Implement security headers to protect against XSS attacks, such as Content-Security-Policy (CSP) and X-XSS-Protection. CSP can help prevent XSS attacks by allowing only trusted sources of content to be loaded on a page, while X-XSS-Protection can help prevent the browser from rendering pages that contain malicious scripts.
  • Session management: Implement secure session management mechanisms, such as session cookies, to protect against session hijacking and other attacks.
  • Secure coding practices: Use secure coding practices to prevent XSS vulnerabilities. This includes using libraries and frameworks that are designed to prevent XSS attacks, testing code for vulnerabilities, and using secure coding practices such as input validation and output encoding.
  • Regular security audits: Regularly audit your system for security vulnerabilities, including XSS vulnerabilities. Use automated tools and manual testing to identify potential issues and fix them before they can be exploited.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Perform output encoding​

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Look for patterns like this:

    public class TestController : Controller
    {
        [HttpGet(""{myParam}"")]
        public string Get(string myParam)
        {
            return "value " + myParam;
        }
    }

  3. And use safe alternatives like HttpUtility.HtmlEncode:

    public class TestController : Controller
    {
        [HttpGet(""{myParam}"")]
        public string Get(string myParam)
        {
            return "value " + HttpUtility.HtmlEncode(myParam);
        }
    }

  4. Test it, ship it 🚢 and relax 🌴

Fixing Insecure Deserialization​

About Deserialization

What is a Deserialization vulnerability?​

Serialization converts complex data structures into a stream of bytes that can be sent or received over a network. Deserialization restores the byte stream to a copy of the previously serialized object. The receiving application can then interact with this deserialized object.

Deserializing attacker-controlled data allows attackers to manipulate serialized objects and pass malicious data to the receiving application.

Alternative terms for Serialization/Deserialization are:

  • Marshaling, Unmarshaling
  • Pickling, Unpickling

Check out this video for a high-level explanation:

What is the impact of Deserialization vulnerabilities?​

Attackers can reuse existing application code in malicious ways which results in a wide range of vulnerabilities such as:

  • Code execution: An attacker can exploit deserialization vulnerabilities to execute arbitrary code on a target system, giving them control over the system and access to sensitive data.
  • Unauthorized access: An attacker can use deserialization vulnerabilities to access and manipulate data or functionality that they are not authorized to access, such as administrative functions or sensitive data.
  • Denial-of-service (DoS) attacks: An attacker can exploit deserialization vulnerabilities to cause DoS attacks, by overloading the system with large amounts of data or by manipulating the data in a way that causes the system to crash or become unresponsive.

How to prevent Deserialization vulnerabilities?​

To prevent deserialization vulnerabilities, it is important to follow security best practices and implement appropriate security measures, such as:

  • Avoid deserialization of untrusted data: Do not deserialize data from untrusted sources or unvalidated user input.
  • Use type checking and input validation: Verify the type and content of serialized data to ensure that it is valid and expected.
  • Use secure deserialization libraries and frameworks: Use secure deserialization libraries and frameworks that can help prevent deserialization vulnerabilities and provide additional security features, such as input validation and type checking.
  • Apply access controls: Apply access controls to limit the privileges and actions that deserialized data can perform, such as preventing it from executing arbitrary code or accessing sensitive resources.
  • Keep software up to date: Keep software and security protocols up to date, as new vulnerabilities and security patches are regularly released.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Don't parse untrusted data with XMLDecoder​

An attacker may pass specially crafted serialized .NET object of specific class that will execute malicious code during the construction of the object, which can result in arbitrary code execution, full application compromise or denial of service.

Unfortunately, there is no simple fix for this. Ideally, no untrusted data is deserialized, such as user input from request parameters, or cookies.

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Look for code like this:

    private void ConvertData(string json)
    {
        var mySerializer = new JavaScriptSerializer(new SimpleTypeResolver());
        Object mything = mySerializer.Deserialize(json, typeof(SomeDataClass)/* the type doesn't matter */);
    }

  3. Follow the steps detailed here

  4. Test it, ship it 🚢 and relax 🌴

Fixing Insecure XML Processing​

About XML External Entities

What is XML External Entities (XXE) injection?​

XML External Entities (XXE) injection is a type of security vulnerability that allows attackers to exploit the processing of XML data by an application.

This occurs when an application accepts XML data from an untrusted source and processes it without proper validation, allowing the inclusion of external entities that can be malicious or contain sensitive information.

As a result, attackers can perform various malicious activities, such as stealing user data, executing arbitrary code, or performing denial-of-service attacks.

Check out this video for a high-level explanation:

What is the impact of XXE injection?​

XML External Entities (XXE) injection can lead to various security threats and risks, such as:

  • Information theft: XXE attacks can steal sensitive information, such as login credentials, credit card details, or other personally identifiable information, by injecting malicious code or entities that collect and transmit user data to attackers.
  • Server-side request forgery: XXE attacks can initiate requests to systems that are accessible from the affected web server.
  • Denial of service: XXE attacks can cause denial-of-service (DoS) attacks by injecting malicious code or entities that consume system resources, such as CPU or memory, leading to system crashes or slowdowns.
  • Arbitrary code execution: XXE attacks can execute arbitrary code on the server by injecting malicious code or entities that exploit vulnerabilities in the application or the underlying operating system.

How to prevent XXE injection?​

To prevent XML External Entities (XXE) injection, it is important to follow security best practices and implement appropriate security measures, such as:

  • Disable external entity processing: Disable the processing of external entities in XML parsers and libraries to prevent XXE vulnerabilities.
  • Use secure parsers and libraries: Use secure parsers and libraries that support secure XML processing.
  • Use input validation: Validate user input to ensure that it is safe and does not contain malicious code or entities.
  • Keep software up to date: Keep software and security protocols up to date, as new vulnerabilities and security patches are regularly released.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Prevent XML External Entity Attacks​

XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received from an untrusted source. Note that in .NET Framework versions 4.5.2 and up, XmlTextReader’s internal XmlResolver is set to null by default, making the XmlTextReader ignore DTDs by default. The XmlTextReader can become unsafe if you create your own non-null XmlResolver with default or unsafe settings.

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Look for code like this:

    // DTD expansion is enabled by default
    XmlReaderSettings settings = new XmlReaderSettings();
    XmlReader reader = XmlReader.Create(inputXml, settings);

    or:

    XmlDocument xmlDoc = new XmlDocument();
    xmlDoc.Load(pathToXmlFile);
    Console.WriteLine(xmlDoc.InnerText);

  3. And replace it with this:

    var settings = new XmlReaderSettings();
    // Prior to .NET 4.0
    settings.ProhibitDtd = true; // default is false!
    // .NET 4.0 - .NET 4.5.2
    settings.DtdProcessing = DtdProcessing.Prohibit; // default is DtdProcessing.Parse!

    XmlReader reader = XmlReader.Create(inputXml, settings);

    or:

    XmlDocument xmlDoc = new XmlDocument();
    xmlDoc.XmlResolver = null; // Setting this to NULL disables DTDs - Its NOT null by default.
    xmlDoc.Load(pathToXmlFile);
    Console.WriteLine(xmlDoc.InnerText);

  4. Test it, ship it 🚢 and relax 🌴

Fixing XPath Injection​

About XPath Injection

What is XPath Injection?​

XPath injection is a type of security vulnerability that allows attackers to exploit the processing of XPath queries by an application.

This occurs when an application accepts user input and uses it to construct an XPath query without proper validation, allowing attackers to inject malicious code or entities that modify or bypass the intended behavior of the query.

XPath injection can affect various types of applications that use XPath queries, such as web applications, document processing software, or online forms.

Attackers can use various techniques, such as crafted queries or filter values, to inject malicious code or entities into the application.

Check out this video for a high-level explanation:

What is the impact of XPath Injection?​

XPath injection can lead to various security threats and risks, such as:

  • Information disclosure: XPath injection can expose sensitive information, such as user data, login credentials, or other types of confidential information, to unauthorized parties.
  • Unauthorized access: XPath injection can allow attackers to gain unauthorized access to applications, perform unauthorized actions, or modify data.
  • Denial-of-service: XPath injection can cause denial-of-service (DoS) attacks by injecting malicious queries or values that consume system resources, such as CPU or memory, leading to system crashes or slowdowns.

How to prevent XPath Injection?​

To prevent XPath injection, it is important to follow security best practices and implement appropriate security measures, such as:

  • Use input validation: Validate user input to ensure that it is safe and does not contain malicious code or characters that can be used for injection attacks.
  • Use parameterized queries: Use parameterized queries and other secure coding practices to ensure that user input is properly sanitized and not used to construct XPath queries directly.
  • Use secure XPath libraries and frameworks: Use secure XPath libraries and frameworks that support secure XPath queries and provide additional security features, such as input validation and parameterized queries.
  • Limit application access: Limit access to applications to authorized users and restrict access to sensitive information and actions.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Prevent XPATH Injection​

If the user input is not properly filtered, a malicious user could extend the XPath query.

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Look for code like this:

    var doc = new XmlDocument {XmlResolver = null};
    doc.Load("/config.xml");
    var results = doc.SelectNodes("/Config/Devices/Device[id='" + input + "']");

  3. And replace it with this:

    Regex rgx = new Regex(@"^[a-zA-Z0-9]+$");
    if(rgx.IsMatch(input))
    {
        XmlDocument doc = new XmlDocument {XmlResolver = null};
        doc.Load("/config.xml");
        var results = doc.SelectNodes("/Config/Devices/Device[id='" + input + "']");
    }

  4. Test it, ship it 🚢 and relax 🌴

Fixing LDAP Injection​

About LDAP Injection

What is LDAP Injection?​

LDAP injection is a type of security vulnerability that allows attackers to exploit an application's interaction with Lightweight Directory Access Protocol (LDAP) servers.

This occurs when an application fails to properly sanitize user input and includes untrusted data in an LDAP query, allowing attackers to inject malicious code or modify the intended behavior of the query.

LDAP injection can affect various types of applications that interact with LDAP servers, such as web applications, directory services, and authentication systems.

Attackers can use various techniques, such as crafted search queries, filter values, or search base paths, to inject malicious code or entities into the application.

Check out this video for a high-level explanation:

What is the impact of LDAP Injection?​

LDAP injection can lead to various security threats and risks, such as:

  • Information disclosure: LDAP injection can expose sensitive information, such as user data, login credentials, or other types of confidential information, to unauthorized parties.
  • Unauthorized access: LDAP injection can allow attackers to gain unauthorized access to LDAP servers, perform unauthorized actions, or modify data.
  • Denial-of-service: LDAP injection can cause denial-of-service (DoS) attacks by injecting malicious queries or values that consume system resources, such as CPU or memory, leading to system crashes or slowdowns.

How to prevent LDAP Injection?​

To prevent LDAP injection, it is important to follow security best practices and implement appropriate security measures, such as:

  • Use input validation: Validate user input to ensure that it is safe and does not contain malicious code or characters that can be used for injection attacks.
  • Use parameterized queries: Use parameterized queries and other secure coding practices to ensure that user input is properly sanitized and not used to construct LDAP queries directly.
  • Use secure LDAP libraries and frameworks: Use secure LDAP libraries and frameworks that support secure LDAP queries and provide additional security features, such as input validation and parameterized queries.
  • Limit LDAP server access: Limit access to LDAP servers to authorized users and restrict access to sensitive information and actions.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Prevent LDAP Injection​

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Look for code like this:

    var searcher = new DirectorySearcher();
    searcher.Filter = "(cn=" + input + ")";

    or:

    var dir = new DirectoryEntry();
    dir.Path = $"GC://DC={input},DC=com";

  3. Follow the instructions provided by WASC-29, or leverage the proper encoder (LdapFilterEncode or LdapDistinguishedNameEncode) from the AntiXSS library:

    // LdapFilterEncode
    var searcher = new DirectorySearcher();
    searcher.Filter = "(cn=" + Encoder.LdapFilterEncode(input) + ")";

    // LdapDistinguishedNameEncode
    var dir = new DirectoryEntry();
    dir.Path = $"GC://DC={Encoder.LdapDistinguishedNameEncode(input)},DC=com";

  4. Test it

  5. Ship it 🚢 and relax 🌴

Last updated on by Stefan Streichsbier