Description
Whenever software processes input, it should make sure that this input is in the expected form. From a functional point of view, this will ensure a high data quality level. Form a security point of view, this will prevent unexpected data from altering the intended execution of the program.
Software processes input from various sources:
• User input from a GUI
• Parameters from a configuration file
• Data from a database
• Data from remote function calls
• Etc.
Risk:
If input is not validated sufficiently, the application processing the data might crash or could be tricked into performing unwanted tasks.
What Do I Get from the SAP NetWeaver Platform?
Web Dynpro (ABAP and Java) performs type validation. Therefore applications don’t have to check for correct data type.
Caveat:
Note that ABAP and Java types are not necessarily identical.
What Do I Need to Do?
Basically you should validate your input. To achieve that goal, you have to provide a validation function for each input variable. You might group the variables (e.g. all input strings) and write one validation function for each group (e.g. string validator), which increases your efficiency. The task of writing validation code can be described as a stepwise procedure. In case of Web Dynpro, the framework automatically does the type validation before you can even access a variable. So the first three steps of the following list have been already performed. Consequently, in Web Dynpro you have to start your additional input validation at the 4th step of the following input validation ‘to do’ list:
1. Existence and length check 2. Canonicalization
3. Type check 4. Range check 5. White list filter 6. Black list filter
These steps will be explained further in the following:
Secure Programming – ABAP 35 / 50
Step 1: Existence and length check
It must not be possible to attack the application simply by omitting a necessary variable or feeding in data packets that are either too long or too short. So, first of all, your validation function shall check if the variable of interest exists and has the correct length.
Step 2: Canonicalization
Canonicalization means, the input variable’s content is transformed into its simplest and shortest representation. Many attack methods depend on the usage of ‘polymorph representation’, i.e. an unusual or overly complicated form that is designed to evade filter mechanisms. So the transformation in its simplest form is fundamental for successful filter mechanisms.
Step 3: Type check
Since attackers should not be able to harm the application by feeding input data of the wrong type to it (e.g. strings instead of dates), the validation function has to check the variable for its correct type.
Step 4: Range check
After that, you should check if the variable's values are in the correct range. Clearly, this is only possible for variables with a definable range of values (like numbers). It is imperative to define the limits exactly here. For all input you should think about where the boundaries lie.
Step 5: ‘White list’ filter
If a variable simply has no clear range of values (e.g. strings) a range check would be pointless. In this case your validation function should contain a list of allowed values and check the input against this instance. Such an instance is called a ‘white list’ filter.
Step 6: ‘Black list’ filter
There may be cases where you even can not implement a white list filter. In this situation, you should write a black list filter function at least. For this is better than doing no filtering at all. Doing nothing here regularly has detrimental effects for the security of your application.
Black lists are fallbacks only!
At this point, it is extremely important to acknowledge that black list filters are vulnerable by nature – and so can be only a fallback solution. Our advice here is very clear: Whenever possible, use a white list filter. If it is not feasible, work towards making it so. Only if it is still absolutely impossible, use a black list filter. In the later case, include this as vulnerability in the application's internal documentation.
How Not to Do It?
Oftentimes input is not validated, for any one of the following reasons:
• Input is not recognizes as such
• The source of input is trusted
Secure Programming – ABAP 36 / 50
• The implicit assumption that someone else already did the validation
• Performance is more important than security
• Insufficient time in the project
Not validating input is a high security risk. Please make sure to precisely weigh the pros and cons whenever you have priorities other than security.
Secure Programming – ABAP 37 / 50
Canonicalization
Description
Canonicalization describes the mechanisms to trace back different polymorphic expressions to a canonical distinct expression. For example, within the context of a search engine the data file ‘Hello World.doc’ may be accessible by any one of the following polymorphic links:
• http://www.sap.com/Hello+World.doc
• http://www.sap.com/hello+world.doc
• http://www.sap.com/Hello%20World.doc
The canonical representation ensures that ‘strange’ but allowed forms of an expression (for example, URL encoding or Unicode) do not pass any filter mechanisms. A polymorph representation of data is not necessarily an attack in itself, but helps to slip malicious data past a filter by “disguising” it.
What Do I Need to Do?
The figure below clarifies what you as a developer have to do:
• Unescape the input and bring it to its shortest or simplest form (canonicalization).
• Validate the input dependent on the output (HTML, database or file system).
o Be aware of double encoded characters.
o Check, if you work in the same character space (Unicode vs. ASCII).
o Remember that combinations of ASCII and HEX characters may represent malicious code. See also chapter “SQL injection”.
o Remember case sensitivity and try to find a ‘capitalized’ canonical form.
• Check against a white list of allowed patterns instead of using a black list.
• Pay attention to the interpreters’ operation mode, because different interpreters might handle the same data in different ways.
Influence each other
canonicalize
•
SQL-Interpreter•
Database•
etc..jsp
•
etc.Figure 3: Dependencies of the Canonicalization Process
Secure Programming – ABAP 38 / 50
Example of a bad filter
Example for the original file, that is allowed to be accessed:
c:\sap\file\test.txt
Example for potentially malicious code:
Example Code 1:
c:\sap\file\test.asp
Access to the file will be denied by the filter of the process, due to the extension .asp.
Such a filter does not accept any .asp or .jsp extensions.
Example Code 2:
c:\sap\file\test.asp::$data
The file ends with ‘data’, which is not interpreted as malicious ending such as
‘.asp’ or ‘.jsp’ by the process filter. Therefore, the file will be accessed by the interpreter.
Example Code 3:
c:\sap\file\test.asp%00de.doc
The file ends with ‘doc’, which is not interpreted as malicious ending such as ‘.asp’
or ‘.jsp’ by the process filter. The file will be opened, because the interpreter does not accept any information following the NULL (%00).
What Do I Get from the SAP NetWeaver Platform?
For Web Dynpro ABAP and for BSP Applications:
The method CL_HTTP_UTILITY=> IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST is available in the Web Application Server/ABAP to check URL-like parameters against a white list of patterns in table HTTP_WHITELIST (table can be maintained in transaction SE16).
This process verifies that the URL from external sources can be accepted. For more information see Security Risk List [SAP Library]. Please also refer to SAP Note 853878.
For HTML Interpreters:
The SAP NetWeaver platform offers several output encoding functions within the ABAP class CL_HTTP_UTILITY to circumvent cross-site scripting (XSS) attacks. See chapter “Cross-Site Scripting (XSS)” for further information.
Further Information
1. OWASP Guide Version 2.0.1 (Pages 185 -191)
http://surfnet.dl.sourceforge.net/sourceforge/owasp/OWASPGuide2.0.1.pdf 2. Security Issues in Web Dynpro for ABAP
http://help.sap.com/saphelp_nw04s/helpdata/en/af/0489ce55002f44a8c927371bedf719/fr ameset.htm
3. SAP Note 853878: HTTP WhiteList Check (security)
Secure Programming – ABAP 39 / 50