Hardening the RAP4 application

[stefjoosten]

The RAP3 application is currently live on URL http://rap.cs.ou.nl/RAP3. It has been built without much consideration of application security. That makes this issue more of an Epic than an issue. Let us start by thinking about the hardening required, making a list of measures and the reasons for wanting them. I have asked @hljonker (Hugo Jonker) to help us with this, so I added him to the team. I expect each item on the following task list to become an issue before we fix the issue. That creates room for sustainable solutions that affect future applications as well.

• Run RAP3 exclusively on https, to prevent http-abuse
• Prevent code injection by escaping all input fields
• Not storing passwords anymore by using OAUTH from the Open University. #291
• Do not give access to web-pages by hand-tweaking of URLs (e.g. anyone can reinstall a database of a generated prototype even when AMPERSAND_PRODUCTION_MODE=true by typing the URL for installing the database directly into the browser.)

Since we have a working RAP3 repository installed at http://52.174.4.78/RAP3/ we can start thinking about consolidating the security measures required for rule repositories.

TODO list

• SSH configuration: prevent that outside users log in as daemon (nor as root) (see for example http://serverfault.com/questions/285800/how-to-disable-ssh-login-with-password-for-some-users/
• Apache: see https://httpd.apache.org/docs/trunk/misc/security_tips.html
• HTTPS-cookies need a flag "Secure", "HHTP-only", and "Samesite". This needs to be addressed in the Ampersand code; not in the deployment.
  Since we have a working RAP3 repository installed at http://52.174.4.78/RAP3/ we can start thinking about consolidating the security measures required for rule repositories.

[stefjoosten]

Currently, the storage of passwords is secure enough, even though they are stored literally in the database. The reason is that the database resides entirely in a container. The only ways of getting information from that database are:

• the API of the RAP3 application, which requires login/password;
• phpmyadmin, which requires admin login/password;
• the database dumps generated by the backup process, which requires admin login/password.

Having said that, I would still like to see passwords to be removed completely.

[RieksJ]

I guess that could be done by calling a (secure) hashfunction in the Atomic-PASSWORD.html template. Currently, further template development (I personally would like to have a template for a drop-down selection box) is postponed until the refactor_ifc-feature branch is merged.

[RieksJ]

@Michiel-s is contemplating the prevention of SQL injections by using so-called 'prepared statements'. The idea is to send the query to the SQL server in two stages. In the first stage, the 'code' is sent (using placeholders for variables), and in the second, only the variables are sent, which allows the server to do whatever is necessary.

[RieksJ]

W.r.t. SSL/https, this has nothing to do with Ampersand or the prototype generator. All it takes is a proper configuration of the webserver you are running and a valid server certificate installed on the webserver. You can get such certificates for free, online, at https://www.sslforfree.com/. You can even configure the stuff such that the certificate (that lives for a few months) is regularly renewed.

[RieksJ]

W.r.t. the task list item "Do not give access to web-pages by hand-tweaking of URLs", it would be nice to be a bit more precise as to what you mean. Given only this text, my 2c would be that every RAP interface should start with an expression that only shows stuff for legit users.