Cross-Site Request Forger Token

Cross-Site Request Forger Token

  
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
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
Update:

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


You can copy/paste from the attachment to jump start your own implementation.

@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).

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?

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.

Paulo Ramos wrote:

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?


Hello Paulo,


Yes, the platform already takes care of that for you with a similar solution as the workaround provides. The platform automatically generates a CSRF token that is validated for each request to make sure the request comes from the expected origin.


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.

Mind that the cross-site request forgery attack is not about packet modification. The fact is if an attacker is able to modify the victim's packets, the set of attacks he might perform can be much more serious than CSRF. This is addressed by a completely different set of solutions.


Cross-site request forgery refers to a set of attacks where the attacker forces the victim's browser to perform actions. If the victim is already logged in, this allows the attacker to bypass the site authentication and perform those actions in the name of the user. 

For example, an attacker could lead the victim to a specially crafted website that leads the user to click on links which perform actions on the legitimate website. Cross-site request forgery prevention by using the token prevents this because the requests sent by the attacker's website will not contain a valid token.


Harlin Setiadarma wrote:

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?


At this time, you still have to use the Forge component I'm afraid.


Thanks for the clarification.

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.