OWASP_Application_Security_Verification_Standard_4.0 - scriptCode
Remote service calls
Treat any parameters entering ScriptCode as untrusted when sending to services
In practice, this means that the rules of the API provided by the REST client must be strictly followed. It defines, among other things, the way of creating the path as a list of individual address segments. Such an interface may seem unintuitive, but it provides greater security.
Sample code
Bad:
const url = "/api/form/" + context.getFirstParameter("form_id") + "/data";
const response = api.rest.v1.get("host", {pathParams: url.split("/")});Good:
const pathParams = ["api", "form", context.getFirstParameter("form_id"), "data"];
const response = api.rest.v1.get("host", {pathParams: pathParms});What are we protecting ourselves against?
Correct use of the API will protect us from attacks involving modification of the target address. Let's go through the sample code, assuming that the form_id parameter comes from a form field. If the user enters "abc/def" and the "/" character into the field, then in the first example it will be treated as part of the address and ultimately we will call the service at "/api/form/abc/def/data", which in practice means we may accidentally call a different service ("/api/form/{x}/{y}/data" instead of "/api/form/{x}/data", i.e. instead of x = "abc/def", we will have x = "abc", y = "def"), whereas the code from the second example will escape this character and send a request to "/api/form/abc%2Fdef/data" (i.e. in the address "/api/form/{x}/data" the x variable will take the value "abc/def").
Handling authorization data for services
Authorization data should never be used directly in ScriptCode. When calling external services (e.g. via api.rest.v1) the platform is responsible for setting the appropriate authorization data in the request to the service. If this is not supported for a given service, a request should be raised with the PO. In the case of services for which implementation is technically impossible or would take a long time, consult the developers on how to safely pass the authorizing data. Regardless of the adopted approach, it is absolutely necessary to avoid storing authorization data (in code, session variables, process variables, form fields) and sending it to the frontend (form fields - including technical fields, session variables).
How to identify problematic data? Unfortunately, due to the variety of authentication methods, it is hard to provide a complete list of such data - use common sense and pay special attention to data that grant access to services. Below is a short list of terms that will help you identify such data - if you encounter them, be alert:
login/user and password,
token,
key,
Authorization header,
API key,
API token,
bearer token,
JWT token.
Downloading remote resources
Any resources we use (e.g. images, documents, card images, etc.) should come from a trusted source. Most often this source is the eximee platform itself or some bank resource, but it should never be the internet. In most cases eximee limits the use of resources to trusted ones only (e.g. in the REST services client you can refer only to services defined by the administrator), however there may be places where such a restriction is not implemented (or impossible to implement). Each time we want to use an external source in the application (in practice, some URL) we should verify whether it is a trusted source (comes from the bank's domain, was included in the requirements) - if the source is not trusted, consult the PO before using it. On the other hand, using external services to implement functionality that does not exist on the platform is unacceptable - in such cases a request for that functionality should be submitted.
If you need to use any link in the application, make sure it is trusted and that its use directly follows from the requirements
If a functionality is not available on the platform, submit a request - do not use external tools
Example problem with external resources and its consequences
In one of the printouts, we had a requirement to generate a QR code based on the application data. Since the platform did not have such functionality, the developer decided to use an external API https://api.qrserver.com. During document generation, the external service started being called https://api.qrserver.com/v1/create-qr-code/?data=${dataFormatted}&size=140x140 (dataFormatted was the data collected in the application), and the result of its call was placed on the printout as an image.
What are the consequences of such an approach:
This is an external service, we do not control it, we have no influence on its downtime periods, it may potentially disappear from the internet
The licensing model was not recognized - we expose our client and ourselves to legal and financial consequences of using the service in violation of the license
We do not know how this external service works - it may potentially generate malicious code that we place on the printout (in the PDF) and it will be executed at the client's side
The data in the dataFormatted variable included such information as the client's address or the amount of cash deposit in the bank - this is data protected by the GDPR and banking law; by using it in the link, we passed it to an external entity (we are causing a data leak) - we expose the bank and ourselves to legal and financial consequences
Sensitive data
Use the sensitive logger to log sensitive data
Sample code
New loggers (preferred method):
New loggers by default treat every passed parameter as sensitive data. To change this behavior, the nonsensitive function must be explicitly used on the parameter. Additionally, new loggers allow parameters to be placed in a text template (we do not do concatenation as in the case of old loggers).
Bad:
Good:
Last updated
Was this helpful?