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.
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?
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
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.
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.
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.
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!
Nordin
Thanks Nordin! I am following up with Outsystems now! Hopefully, it will be the same as you experienced.
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.