‫ IDS15-J and IDS16-J

ID: IRCAR201503249
Date: 2015-03-10
 
IDS15-J. Do not allow sensitive information to leak outside a trust boundary
 
This rule is a stub.
 
Several guidelines are instances of this one, including ERR01-J. Do not allow exceptions to expose sensitive information, DRD00-J. Do not store sensitive information on external storage (SD card) unless encrypted first, and DRD11-J. Ensure that sensitive data is kept secure.
Risk Assessment
Leaking sensitive information outside a trust boundary is not a good idea.
 
 
 
IDS16-J. Prevent XML Injection
The extensible markup language is designed to help store, structure, and transfer data. Because of its platform independence, flexibility, and relative simplicity, the extensible markup language (XML) has found use in a wide range of applications. However, because of its versatility, XML is vulnerable to a wide spectrum of attacks including XML injection.
A user who has the ability to provide input string data that it is incorporated into an XML document can inject XML tags. These tags are interpreted by the XML parser and may cause data to be overridden.
An online store application where the user has the ability to specify the quantity of an item available for purchase might generate the following XML document:
 
An attacker might input the following string instead of a count for the quantity:
 
In which case the XML resolves to:
 
An XML parser may interpret the XML in this example such that the second price field overrides the first, changing the price of the item to $1. Alternatively, the attacker may be able to inject special characters, such as comment blocks and CDATA delimiters, which corrupt the meaning of the XML.
Noncompliant Code Example
In this noncompliant code example, a client method uses simple string concatenation to build an XML query to send to a server. XML injection is possible because the method performs no input validation.
Compliant Solution (Input Validation)
Depending on the specific data and command interpreter or parser to which data is being sent, appropriate methods must be used to sanitize untrusted user input. This compliant solution validates that quantity is an unsigned integer.
Compliant Solution (XML Schema)
A more general mechanism for checking XML for attempted injection is to validate it using a Document Type Definition (DTD) or schema. The schema must be rigidly defined to prevent injections from being mistaken for valid XML. Here is a suitable schema for validating our XML snippet:
 
The schema is available as the file schema.xsd. This compliant solution employs this schema to prevent XML injection from succeeding. It also relies on the CustomResolver class defined in IDS17-J. Prevent XML External Entity Attacks to prevent XML external entity (XXE) attacks.
Using a schema or DTD to validate XML is convenient when receiving XML that may have been loaded with unsanitized input. If such an XML string has not yet been built, sanitizing input before constructing XML yields better performance.
Risk Assessment
Failure to sanitize user input before processing or storing it can result in injection attacks.
 
Ref:
https://www.securecoding.cert.org

نظرات

بدون نظر
شما برای نظر دادن باید وارد شوید

نوشته

 
تاریخ ایجاد: 23 اسفند 1393

دسته‌ها

امتیاز

امتیاز شما
تعداد امتیازها:0