Hello everyone,
I'm facing a challenge in my OutSystems application and would like to get some guidance on how to handle it. Recently, during a pentest report, I discovered that my application is vulnerable to replay attacks due to the lack of Rate Limiting implementation.
The tests revealed that an attacker can send the same request repeatedly (e.g., by clicking the "Save" button multiple times) using tools like Burp Suite, which can result in undesired effects such as the creation of multiple duplicate records.
I'd like to know if anyone has encountered this issue before or has experience in OutSystems applications to prevent this type of attack. What are the best practices or recommended approaches?
Hi @Bruno Rendeiro
you can add an index to make the saved record unique on the database level
or you can add validation upon saving to check if the record already exists
or you can add unique text/token/otp with/without expiration to save on the database and validate it per saved transactions
or encrypt transactions then decrypt every transaction
you can also add a captcha if needed
or JWT token
https://www.outsystems.com/forge/component-overview/1853/jwt-o11
Dear Bruno ,
I am not really well versed with React but I do have a few suggestions.
1)Regarding i.e hitting save button multiple times implement design pattern listed below.
https://success.outsystems.com/documentation/11/developing_an_application/design_ui/patterns/using_mobile_and_reactive_patterns/utilities/button_loading/
2)Using burp suite you say , i.e that means all that they're doing is adding a sniffer then sending the same request to server several times. This also suggest that you have CRUD operation in client actions which is bad.
For this my suggestion would be to add extra code to your validate your session so that this becomes moot (Add getUserId inside the server action before saving) Although if attacker is well versed they might foresee this and try to hijack a session as well before doing this. So this might have few pitfalls here and there.
3) If you want to make validation more stricter I'd suggest introduction a way to extend user module to also save UUID or GUID a unique specifier when user logs in (Please note these just my suggestion on top my head). Since I don't what type of authenication you're using I'll attach a demo with simple outsystem authentication used.
Have timer clear out this table at the end of day.I attached a POC for your knowledge , it might some issues well all my three points are implemented in there.
Please note and this is important , do not use the UUID or GUID as input param in client actions anywhere. It should be validated in only server actions only. Input params in client actions will be exposed a xhr request in reactive so you should avoid that.
Further more please check this page out if this said vulnerability is already disclosed if so , you might get further information on how to resolve it.https://success.outsystems.com/support/security/vulnerabilities/https://success.outsystems.com/documentation/best_practices/security/reactive_web_security_best_practices/Do let me know the results if you're gonna submit this POC to your sec-ops team Kind regards,Craig
Hi @Bruno You can also take care of the following points.-Create reusable server-side logic or modules to enforce rate limiting for the identified operations. -Specify the maximum number of requests allowed within a certain time period. -Use Built-in features such as Session Variables, Timers, and Aggregate Queries to implement rate-limiting logic efficiently. -Can store request timestamps in session variables and use timers to periodically reset the request count. -Monitor system logs and usage metrics. -Implementation of OutSystems authentication and authorization (Role-based access, session timeouts, etc.) Thanks Shriyash Dixit