Security question about basic queries

Security question about basic queries

I have some entities that reference an ID from the users table, such as "Technical Owner" of a service.  So, I have the id in the entity joined to User.Id.  When I've tested these simple queries and looked at the SQL that's generated, I see that the default simple query grabs the entire User.Id table, including the User.Password record.  

Even though the table that is displaying the query results doesn't include that field, it seems like a big security risk to send an encrypted password to the web front end when it isn't explicitly necessary.

Maybe I should be filing this a a bug or feature request, but it seems like it would be a good idea for any joins created by a simple query that reference the Users system entity should not query the User.Password column.

Can anyone from Outsystems comment on the security of this?  What kind of security testing has gone into the development of the platform.  For simple web apps with the usual List, Show, Edit pages, has Outsystems run fuzzers, SQL injection and other web application security tools against websites that use the standard widgets?

Just curious.

Hi Craig,

Your concerns are totally valid and it looks you're really getting the feel of the platform internals :)

The platform will optimize all your simple queries and only bring the database fields that are used in the screen. As such, if you have, for instance, a TableRecord bound to the results of a simple query in the Preparation of your screen and that TableRecord only shows Machine.Name and User.Name (the technical owner) only those two columns will be fetch from the database. This should answer your security risk, but also a performance issue that might exist if you used a long set of Joins just to fetch a single column in one of the joined tables.

If you have user actions that perform simple queries and bind the results to a structure (instead of using the simple query directly in screens) then the whole information to fill the record is fetched (as the platform doesn't know which fields are you going to use). In those custom cases, you have control over the data you're exposing. However any data is only stored server side and the platform also does a thourough job of only keeping the required data in the ViewState (ex: if the column is not being used in any screen action logic, it doesn't need to be put on the ViewState). This keeps the html rendered size much smaller.

In any case, the password you mentioned is a non-reversible hash (from the encrypted password there is no way to get the readable password).

Every parameter used in simple queries is protected against SQL injection. Even on advanced queries, unless you use the Expand Inline property of a parameter, every parameter is also protected against SQL injection.

Hope this helps your curiosity :)
Thanks, Goncalo.

What hashing algorithm do you use and are you salting the hashes?
Hi Craig,

The hashing algorithm is MD5 and it is salted with an internal text. If configured in the users espace (6.0+), the salt also contains the username.