Security Enhancements

  
Hi All,

I'm fairly new to OutSystems and loving the platform.

We recently went through a round of penetration testing using OutSystems 8.0.1.16, and I'd like some advice on how to resolve some of the issues please.

1. When a user logs in, the session seems like it never times out. I've read up that I should disable persistent login. I'm using User_Login action to log a user in, but Persistent login isn't a property?!

2. On the topic of sessions, is there a way to enable that one session per username / password combination is enforced?  I.e. that if the same username and password is used to log in from a different location and it is already logged in, an error message is displayed to state that user is already logged in.

3. Is there a built in way to enforce account lockout? I.e. if a user attempts to login 3 times with the wrong password, his account gets locked - Only admin users can then unlock the account.

4. How do I implement Network-Based Security? I.e. allowing internal only access to certain eSpaces

Kind Regards,
Charl Lotter
Hi,

1.
The parameter is named 'RememberLogin' in the User_Login action (set it as false).

2.
Use your data model (e.g. one entity with UserId, LastRequestOn, SessionCookieId...) to keep track of active user sessions. I'd set a cookie for identifying each location (browser). When logging in the user, you'd check if he is already logged in from another browser.
Note that, due to the way web apps work, it may be hard understanding if the user is still actually using the application (you don't want to rely on explicit logout - one may simply close the browser). One possible way would be using the OnBeginWebRequest event action (tip: right-click Actions in SS...), to keep track of the user activity. After some minutes of inactivity, you may allow him to login from another location.

3.
You can change your login screen to store the number of failed attempts (in your data model), and then act accordingly in the login flow.
Note that it will be easy for a malicious user to block someone else's login, if he knows the username.

4.
- Easiest option would be using the Internal Network, configured in the Configuration Tool. You need access to the front-end in order to use the configuration tool, though (not an option if you're using a personal environment).
- Or you can get the client's IP address (again, with OnBeginWebRequest) and match it against a list of approved IPs.
- Other option is using Zones, which implies having an environment with multiple front-ends, while some of those FEs are behind a firewall so that they are unreachable from outside the organization. On this scenario, you'd configure a zone (e.g. 'Intranet') including those internal FEs and the list of internal eSpaces.
Thank you Paulo,

I'll get working on your suggestions :)
Hi Paulo,

I implemented all of your suggestions and they are working beautifully!

One additional question please: Can one enforce cookies to a solution?

Kind Regards,
Charl Lotter
Or check that they have it enabled before getting to the login screen?
Hi,

You can check if cookies are enabled via javascript (see here and here). If they're not, you can have your script redirect the user to an error screen (directly or by clicking an hidden button, for example).

Another method (server side) would be setting a cookie, and then redirecting the user to another screen (via a script or meta tag). On the second screen, you'd check if the cookie is indeed present.

Note that, if you're using authentication or session variables in your app, this will only work if the browser has cookies anabled anyway (by default). There's an ancient setting in Service Studio that allows you to revert to a no-cookies needed approach: property Use Cookies in the eSpace properties (root node in the right-side tree).
Excellent stuff, thanks Paulo :)
"2.
Use your data model (e.g. one entity with UserId, LastRequestOn, SessionCookieId...) to keep track of active user sessions. I'd set a cookie for identifying each location (browser). When logging in the user, you'd check if he is already logged in from another browser."

How does one uniquely identify the browser?
Hi Charl,

I think what Paulo was sugesting was for you to generate a new random guid and set a cookie with that value. If on the login it doesn't have the correct cookie value then it will be another browser.

Regards,
João Rosado
Thanks João,

That makes a lot of sense :)