Cross-Site Request Forger Token Exposure

According to the Documentation, CSRF attacks are handled automatically in Outsystems 10.

Using Burp, I have found a way in Outsystems 11 to perform a CSRF attack.

(1) Have we gone backwards in OS11?
(2) Is there anything that needs to be done in order to handle CSRF attacks by default?

It was quite a straightforward process.

In my web application, I intercepted the form submission, generated a CSRF PoC, loaded it into the browser where my active session resided and maliciously updated the content of my form.

Any advice appreciated. Thanks.

mvp_badge
MVP

Hi Kieran,

When you sau "In my web application, I intercepted the form submission", what do you mean exactly? What kind of web application? And how did you interecept the form submission?

mvp_badge
MVP

Hi Kieran,

Not sure why you think this was something only working in V10. The current v11 documentation is valid too.

Security/How_the_OutSystems_Platform_Helps_You_Develop_Secure_Applications/Protecting_OutSystems_apps_from_Cross_Site_Request_Forgery_attacks

Did you follow the advices of above document?

Regards,

Daniel

OutSystems built-in protection

  • For traditional web applications the osVisitor cookie stores a token that protects against CSRF attacks. Find the token definition in this article.


From reading that, and that fact OS provides the CSRF protection "Out of the box", I'm struggling to determine what needs to be implemented.


@Killian... I'm running an OS 11 Web Application with a standard form on an HTML page. I'm using Burp Suite to intercept the form submission and generate a CSRF attack.




mvp_badge
MVP

I'm sorry, but any succesful man-in-the-middle attack will comprise your security. If you have a secure HTTPS connection, you cannot play out this attack, right?

We do have a secure HTTPS, however, I can create this problem with a valid user session and using Burp Suite.

It was highlighted on a recent pen test as:

CVSS Score: 5.4
Impact/Probability: Medium/Low

So I am looking into resolutions. 

mvp_badge
MVP

Yes, if you were able to authenticate yourself and have a valid user session you can do this, as you said you authenticated yourself, you have valid credentials to start the application.  To avoid that you now can make unauthorized  server request, the application need to authorize every server call. 

More information read Reactive Web Security Best Practices  for Reactive Web Applications.

For mobile applications, consider to use the SSL Pinning Plugin to avoid man in the middle attacks.

mvp_badge
MVP

Hi Kieran,

Because of the scenario you describe above, I'm leaning towards this being a Replay attack and NOT a CSRF attack. As Daniel said, that will only work if you are able to intercept the request including the valid user session ID that comes with it.

Assuming we are talking about a Traditional Web Application (since you have it tagged in your original post), allow me to refer you to this post were I describe in some detail how the platform protects TWAs against CSRF attacks (also in version 11).

I once had this same finding coming out of a penetration test and have contacted OutSystems support about it. The outcome was it turned out to be inaccurately flagged as a CSRF attack and after a retest, the third-party behind the penetration test has concluded the same.

Hope this helps!

Regards,

Nordin

Thanks Nordin! I am following up with Outsystems now! Hopefully, it will be the same as you experienced.

mvp_badge
MVP

You're welcome Kieran.

If it makes it any easier, you can refer them to CaseId #2393895.

It would also be great if you could report back here with the outcome.

Regards,

Nordin

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.