-
Notifications
You must be signed in to change notification settings - Fork 0
guide security quick S5 Basic Input Validation
This package describes basic input validation controls.
The runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.
Purpose: Memory overflow attacks (be it stack or heap overflows) allow the attacker to have read or read/write access to the applications memory, which can impact the integrity or accessibility of the application (see OWASP).
Solution: Secure by design. Java virtual machines protect its memory from direct user access and prevent this way buffer overflows as result of developers coding mistakes. Buffer overflows in the virtual machines itself are not improbable, but the machines itself are rigorously tested and the probability of such overflows to occur is negligible.
All input validation failures result in input rejection and are logged.
Purpose: Data validation routines are the first line of defence against common attacks like e.g. injection.
Solution: This requirement should be understood as a good coding practice. Every time untrusted input data is validated, validation failures must always lead to either stopping the program flow itself (by throwing an exception with roll back of the uncommitted data) or continuing the program flow but rejecting the input (should ideally happen at the same place in code as the validation routine).
Another good coding practice is preferring whitelisting over blacklisting for the means of data validation. Whitelisting means allowing a program to continue if and only if the white listing (strongly narrowing) rules are met. In case of a mistake in the whitelisting function the program flow will terminate and the application will fail safe.
Blacklisting on the other hand terminates the program flow in case the black listing function recognizes the input as invalid or malicious. In case of a mistake in the blacklisting function, the program will continue with invalid (potentially malicious) input which can result in a security incident.
All input validation or encoding routines are performed and enforced on the server side.
Purpose: Attacker can easily bypass all client side security controls.
Solution: This rule seems obvious at the first glance, but in fact it requires a certain level of development discipline.
It’s a common development scenario, that user input is validated on the client side by means of Java Script (for performance reasons) or that multiple requests to the application (with different input data structures) are handled by one and the same server command. In both cases a strong server side validation should check and enforce at least the same rules as the client side does.
The challenge here is, that the server side validation routines can not be tested as part of functional tests running on the clients UI, as such tests will only touch the client side and its validation. The developers should choose either unit tests or dynamic code analysis (manual test supported by proxy tools like Burp or OWASP ZAP) to ensure the server side validation works correct.
The runtime environment is not susceptible to SQL Injection, or that security controls prevent SQL Injection.
Purpose: SQL injection problems arise from insufficient separation of the SQL query template from the template parametrization and happen in cases where the SQL statement is glued together using e.g. string concatenation of the SQL query and unvalidated user data. To get a good understanding about what SQL injection problems are please refer to the OWASP pages.
Solution: The hibernates JPA API offers a clean way to separate the SQL code from its parametrization which can be used to handle static queries. This approach has been already accurately described in the devonfw4J documentation.
For dynamic queries it is advised to use QueryDSL (full SQL abstraction layer) as also described in the devonfw4J documentation.
As often the case in security relevant topics, no one can say with 100% confidence that both approaches will always offer SQL injection protection. For practical purposes one can safely assume, that the probability of mistakenly writing SQL injection vulnerable code using one of the mentioned approaches is negligible.
The runtime environment is not susceptible to LDAP Injection, or that security controls prevent LDAP Injection.
Purpose: Lightweight Directory Access Protocol (LDAP) Injection is an attack used to exploit web-based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands, such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.
Solution: For Java consider using LDAP Spring. Using its filters and query builders considerably reduces risk, because dangerous characters are properly escaped. Do not write own LDAP authentication - use Spring Security instead.
The runtime environment is not susceptible to OS Command Injection, or that security controls prevent OS Command Injection.
Purpose: You wouldn’t like an attacker to execute arbitrary shell commands on your server, would you? OS command injection vulnerabilities in Java can arise by passing unvalidated user input to parametrize system calls using the class Runtime.
Solution: Our applications shouldn’t usually have any need to to run OS commands at all. In rare cases such functionality is needed no parametrization with untrusted values should be allowed or the untrusted value should be validated by using a whitelisting (see S5-2) approach. == S5-7 The runtime environment is not susceptible to XML External Entity attacks or that security controls prevents XML External Entity attacks.
To understand the threat of external entity attacks please refer to OWASP pages. Also note, that in Java the XML streaming API enables external entities by default, so all Java applications that handle user XML input are potentially vulnerable to this kind of attack.
To turn external entities off use following approach:
SAXReader reader = new SAXReader();
reader.setFeature("http://xml.org/sax/features/external-general-entities", false);
Document document = reader.read("<path to file>");
SAXBuilder builder = new SAXBuilder();
File xmlFile = new File("<path to file>");
builder.setExpandEntities(false);
Document document = builder.build(xmlFile);
JAXBContext jc = JAXBContext.newInstance(UnmarshalledClass.class);
XMLInputFactory xif = XMLInputFactory.newFactory();
xif.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false);
xif.setProperty(XMLInputFactory.SUPPORT_DTD, false); // if not needed
XMLStreamReader xsr = xif.createXMLStreamReader(new StreamSource("<path to file>"));
Unmarshaller unmarshaller = jc.createUnmarshaller(); UnmarshalledClass object = (UnmarshalledClass) unmarshaller.unmarshal(xsr);
The runtime environment is not susceptible to XML Injections or that security controls prevents XML Injections.
Purpose: To get a good understanding of XML injections problems please refer to the OWASP pages.
Solution: The usual case how XML injection vulnerabilities are introduced in an application is manual string concatenation parametrized by unvalidated user input. The best solution to prevent such problems depends on the context, but is usually solved by tools and libraries offering full XML abstraction like JAXB, XStream (XML-Java marshalling and demarshalling), dom4j, JDOM (XML building and reading).
All string variables placed into HTML or other web client code is either properly contextually encoded manually, or utilize templates that automatically encode contextually to ensure the application is not susceptible to reflected, stored and DOM Cross-Site Scripting (XSS) attacks.
Purpose: Please refer to the OWASP pages and the OWASP Top 10 list.
Solution: TODO: we definitely should write about how Angular handles this case and what can go wrong with using JQuery the wrong way. This is definitely a task for someone who knows both.
The application is not susceptible to Remote File Inclusion (RFI) or Local File Inclusion (LFI) when content is used that is a path to a file.
Purpose: Please refer to OWASP pages to learn about Local and Remote File Inclusions.
Solution: This issue must be properly handled by the developer. A good hint how to handle this kind of situation is to canonicalize path names before validation.
This documentation is licensed under TODO License (CC-ND?, proprietäre Lizenz?)