Security

Contents[Hide]


 

1. Java Authentication / SSO / Custom authentication modules integration

If you use already any Java-based authentication library or authentication service,
you can invoke any Java API from nashorn API. So there is not much difference from what you usually do. 

If your authentication module provides you a “user” object in session, you can get it like this :

var user = env.getSession().getAttribute("user");

Or you can obtain java.security.Principal from HttpServletRequest.getUserPrincipal

var principal = env.getRequest().getUserPrincipal();

 

2. SQL Injection

SQL Injection is prevents by default when using parameter binding

 

Example 1:

SELECT * FROM MY_TABLE WHERE FIRST_NAME = :p.firstName  /* no SQL Injection */
 

SQL Injection must be prevented programicaly when the data coming from the user is not used as a bind expression. 

 

Example 2 (SQL Injection vulnerability):

SELECT <%=p.columns %> FROM MY_TABLE /* SQL Injection vulnerability */
 

Example 2 (SQL Injection vulnerability fixed ):

<% 
   if (! p.columns .match(/^[a-z0-9_,\s]*$/i)) // only alphanumeric, underscore and commas allowed to prevent SQL Injection
       throw "Illegal 'columns' value"+p.columns; 
%>
SELECT <%=p.columns %> FROM MY_TABLE  /* no SQL Injection, because of whitelist charecters filtering */

 

3. Cross Site Request Forgery (CSRF)

CSRF vulnerability and how to implement the protection again it in Java is well explained in Spring documentation:

https://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html

 

The same documentation explains an issue that happened if the CSRF token is stored in the HttpSession, so as soon as the HttpSession expires the CSRF Token gets invalid and required additional handling to me programmed.

LightLink.io handles all CSRF issues automatically.

When the page is loaded the Token is generated by the server and stored client-side in JavaScript in-memory variable “LL.JsApi.CSRF_Token”. Each server-side request with LightLink API will include automatically that token to the request data.

In case of CSRF Token expiration, nothing needs to be programmed.

Once an invalid CSRF Token is detected by the server, it will return to the client the JSON: he next server request will return {"success":false,"csrf_error":true} JSON response. This erroris detected by client side LightLink API and an token renewal request is sent to the server : POST /csrfTokenRenew

Response contains the new Token that will be stored in LL.JsApi.CSRF_Token and the server-side request (the one that revealed the CSRF Token expiration) will be repeated with the new one. Upon response from the server the same Callback is invoked.

So for the underlying application all that logic is transparent. No exception is raised and the Callback is invoked with the data from the final response.