41 lines
1.2 KiB
Plaintext
41 lines
1.2 KiB
Plaintext
|
==== Validation
|
||
|
|
|
||
|
|
As a rule of thumb, the best approach to protect against injections is to
|
||
|
|
systematically ensure that untrusted data cannot break out of the initially
|
||
|
|
intended logic.
|
||
|
|
|
||
|
|
For XPath injections, the cleanest way to do so is to use parameterized queries
|
||
|
|
if it is available for your use case. Else, the most secure way to do so is to
|
||
|
|
validate the input before using it in an XPath query.
|
||
|
|
|
||
|
|
Create a list of authorized and secure strings that you want the application to
|
||
|
|
be able to use in a query. +
|
||
|
|
If a user input does not match an entry in this list, it should be rejected
|
||
|
|
because it is considered unsafe.
|
||
|
|
|
||
|
|
The list can be either a regex string, an array, or validators on specific
|
||
|
|
ranges of characters. If you use regexes, choose simple regexes to avoid ReDOS
|
||
|
|
attacks.
|
||
|
|
|
||
|
|
*Important note*: The application must do validation on the server side. Not on
|
||
|
|
client-side front-ends.
|
||
|
|
|
||
|
|
As a last resort, the most important security mechanism is the restriction of
|
||
|
|
XPath metacharacters, such as:
|
||
|
|
|
||
|
|
* `"`
|
||
|
|
* `'`
|
||
|
|
* `/`
|
||
|
|
* `@`
|
||
|
|
* `=`
|
||
|
|
* `*`
|
||
|
|
* `[`
|
||
|
|
* `]`
|
||
|
|
* `(`
|
||
|
|
* `)`
|
||
|
|
|
||
|
|
For Java, OWASP's function
|
||
|
|
https://www.javadoc.io/doc/org.owasp.esapi/esapi/latest/org/owasp/esapi/Encoder.html#encodeForXPath-java.lang.String-[`encodeForXPath`]
|
||
|
|
allows sanitizing these characters automatically.
|
||
|
|
|