XSSF - CSR Issue

[rameshprakash]

Hi,

We are using Smartclient12.0 power edition and we are facing some issue on Content-Security-Policy in Smartclient. By adding below line in the response

response.addHeader("Content-Security-Policy", "script-src 'self' 'unsafe-inline' ");

isomorphic is not loading by adding above line in the http response.

We have defined .jsp <%@ taglib uri="/WEB-INF/iscTaglib.tld" prefix="isomorphic"%>

We tried in latest Google Chrome, Edge and Firefox, we are getting the same error.

Please refer the attached document for detail error message.

[Isomorphic]

Please see this thread, this is not a supported setting, and not a supportable setting (being forced to never use eval would slow things down, and make certain features impossible), and not a useful setting from a security point of view.

[rameshprakash]

We are using Smartclient12.0 power edition. Is there a way to generate the token and pass on each HTTP request.

[Isomorphic]

If you are talking about a CSRF token, typically whatever authentication system you are using provides the token. Then you can simply add it to RPCManager.actionURL.

[rameshprakash]

We have around 300 places the below method. How do I append the token in the request and response. Do I have to set explicitly in the response every time.

isc.RPCManager.sendRequest({
actionURL : "../../ViewProcessor",
showPrompt : true,
willHandleError : true,
data : {
Operation : "fetchFields",
viewName : viewName
}
});


I have tried something like below. I do see the request and not in the response. Please share some URL do we have any example for CSRF in smartclient 12 power edition.

isc.RPCManager.sendRequest({
actionURL : "../../ViewProcessor"+"?token="+getCSRFToken(),
showPrompt : true,
willHandleError : true,
data : {
Operation : "fetchFields",
viewName : viewName
}
});

[Isomorphic]

We just told you above:

If you are talking about a CSRF token, typically whatever authentication system you are using provides the token. Then you can simply add it to RPCManager.actionURL.

Just set RPCManager.setActionURL(), once, and you're done.

If you are using multiple actionURLs for different kinds of requests, then you haven't followed the SmartClient architecture correctly: see the Queuing discussion in the QuickStart Guide. By using a single URL you can combine any set of requests together, key for transactions and many other use cases, as well as, of course, greater efficiency.

In that case you will have to add the token in lots of places instead of just one. Let us know if you have quite a lot of different URLs and can't easily correct your architecture, as there is another, more difficult approach.

[rameshprakash]

Question :

1) For each IDA/RPC call, how do we have to regenerate the token and set it in the next upcoming request.

Please provide the sample example of CSRF where you have single actionURL for all request.

Our Requirement :-

For each and every DSRequest / RPCRequest, we have to attach the token and in the server processor the token should be invalidated and we will regenerate and send the new token. This new token should be attached for the next upcoming request.

Request 1: Client to Server

{
"actionURL":"../../InvoiceProcessor",
"showPrompt":true,
"prompt":"Reconciling...",
"transport":"xmlHttpRequest",
"promptStyle":"cursor",
"willHandleError":true,
"newCsrfToken":"ipkr-7N-QK4-tP1GjTazv3xTTJ2Bpx3_6Kzbsa5PS-FRW0vWI3Tx!1783988662!1607055684478"
}

In the server, we have to invalidate this token and regenerate the new CSRD token and attach in the next request.

Request2:

{
"actionURL":"../../InvoiceProcessor",
"showPrompt":true,
"prompt":"Reconciling...",
"transport":"xmlHttpRequest",
"promptStyle":"cursor",
"willHandleError":true,
"newCsrfToken":new generated token from the previous request1.
}

[Isomorphic]

Regenerating the token for every request is a very bad idea, which doesn't really add to security, just complexity, and we would strongly recommend against it.

In a very linear web application, like from the early 2000s, a CSRF token per request means that you would be able to detect that the client is issuing requests in an unexpected order, as a security measure. For example, if a client is looking at Form B, and you get a CSRF token that the server provided when looking at Form A, that's a a red flag that something is wrong.

But modern applications submit requests in an order that cannot be predicted by the server, since the order that the requests are submitted by the client are affected by caching, and by the fact that modern applications may navigate through several screens and perform several operations without contacting the server. And this doesn't even cover offline capabilities, relogin, and other scenarios where you are creating needless complexity.

So for a modern application, you are at best guarding against the possibility that an attacker can acquire the CSRF token once but not again, which is a very fringe scenario in terms of the ways in which a CSRF token might be acquired by an attacher.

But if you are forced to do this unnecessary work, use RPCManager.transformRequest:

https://www.smartclient.com/smartcli...ansformRequest

... and put all of your responses through universal response processing that grabs the new CSRF token and then calls the request-specific callback.