803
Views
15
Comments
Solved
Cross-Site Request Forger Token
Question
Hi,

as anyone implemented any kind of CSRF Token synchronization in Outsystens our was able to use .net ViewStateUserKey.

Does anyone know is outsystems as any kind of Cross-Site Request Forgery protection?



Best Regards
Staff
Rank: #64
Solution

Debasis Sahoo wrote:

Good suggestion to generate token but apart from it, strange thing is that i am using ver.10 and still facing issue with CSRF.

The best part is entire application is routed with SSL configured at server and the hacker is able enough to modify the packets.

Hi Debasis,


What's the issues that you are still facing with CSRF?

In this article says  "Cross-site request forgery (A8)...
OutSystems includes in each page, by default, a token-based mechanism that ensures that the web page was generated for a given user in a given environment. (...)".


In other words, CSRF issue should be solved out of the box with V10.


Staff
Rank: #595
Hi Antonio,

Maybe you can find a better solution, but here's one that works:
- Use GenerateGuid to create a token on session start, and assign it to a session variable;
- Add an hidden field to a common web block with the value of the session variable;
- Validate the hidden field against the session variable in OnBeginWebRequest. To avoid having different logic for the first session page (and make the code slightly more efficient), I run the validation only for POST requests.

Like this, a successful attack would have to guess the GUID generated for the current session of the victim, which seems extremely unlikely.

I hope this helps.

Joao
Staff
Rank: #595
Update:

GenerateGUID is not a secure random number generator.
Use CryptoAPI.GenerateAESKey instead, with at least 128 bits.


Staff
Rank: #595
You can copy/paste from the attachment to jump start your own implementation.

CSRF.oml

mvp_badge
MVP
Rank: #26
@Joao:
I've checked your version and extended it to create a working version out-of-the-box.
I've also replaced the GenerateUID with the CryptoAPI.GenerateAESKey(256).

CSRF.oml

Staff
Rank: #23

Hi João,

I know the thread is old but wanted to clear this up. :)

Is it correct to say that this workaround is no longer required for the latest OutSystems release, as indicated here?

I'm interested too...

Waiting for response...

This is something that Outsystems should have done by default.

Also how about SSL pinning, do we still have to use Forge component or have been included now inside Outsystems?

Rank: #1202

Good suggestion to generate token but apart from it, strange thing is that i am using ver.10 and still facing issue with CSRF.

The best part is entire application is routed with SSL configured at server and the hacker is able enough to modify the packets.

Thanks for the clarification.

Staff
Rank: #92

Hi, just came back to this thread researching for a way to secure my REST API. It is my understanding that although the platform currently mitigates Cross-site request forgery (OWASP.2013.A8) attacks, this is not done automatically on platform Exposed REST APIs, so that mitigation is highly recommended as per suggestions in https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/How_OutSystems_Platform_helps_you_develop_secure_applications/05_Protecting_OutSystems_apps_from_Cross_Site_Request_Forgery_attacks#section_1

Rank: #421

Hi All,

Facing one issue in traditional web application regarding CSRF attack, generated support case and OutSystems saying its not CSRF attack instead its Replay Attack, In this VPAT team capture one request from application and save request as html. Then reuse that for further action. OutSystems suggested below solution.


Based on this specific context, we can conclude that the exploit you are reporting is a Replay Attack and not exactly a CSRF attack. In any case, there are some measures that can be put in place to considerably reduce the attack surface of both attacks.

The most effective of these measures is making sure that you are forcing HTTPS for all your applications, which is something that you already enabled in your environment. HTTPS prevents requests from being captured since they are being encrypted.

The second effective measure, based on your specific use case, is to follow our recommendation to implement the logic of a 'Cookie to header token' - this is an anti-CSRF technique which relies on the same-origin policy by checking the headers programmatically on every web request. You can implement this by following the steps below: 


In above am not sure what is "Cookie to header token' and how to implement it. Kindly suggest if any one have some idea.

Best Regards.