Review of security

Referring to the Tech Club web application, we will now consider some of the many ways we can be attacked, and how (or if) we are protected against them. Note that the site as it stands is not protected against every form of attack. Further protective measures are included in the guides following this one.

Server / Network

Attack name Description Our defenses
(Distributed) Denial of service (DDoS / DoS) The attacker overwhelms the server with requests, using his own computer (DoS) or many computers (DDoS). AWS provides DDoS protection automatically.

If a lone IP is DoSing us and gets past Amazon, we would exclude it with an Apache Deny from rule (note that we can only be DoS'd via HTTP, all the other ports are closed by the AWS firewall, see Port / password attack below).
Exploit attack The attacker exploits a software vulnerability to access or damage the server. This is avoided by doing apt-get update / apt-get upgrade regularly, and by keeping an eye on the tech news (e.g. the recent Heartbleed bug was very well publicized).
Packet sniffing The attacker intercepts the internet traffic (including passwords) between the user's computer and our web application or our service accounts, most easily when the user is on a public Wifi. None yet on the web application. This is fixed by adding SSL/TLS encryption to the site. This is shown in the following guide Add SSL/TLS encryption.

Packets sent when accessing our service accounts are encrypted by the respective companies.
Port / password attack The attacker attempts to access our server via a vulnerable port. The virtual server is well locked down by the AWS firewall. Only the HTTP port is open to the internet. The SSH port is only open to our IP and the SSH password should be generated using KeePass and unguessable.

Web application

Attack name Description Our defenses
Cross-site scripting (XSS) The attacker enters malicious Javascript into a form field and/or the database, and when this is echoed back to his or any other user's browser, the malicious code is executed. Firstly, every user input goes through the function f_input_accept, which removes "<" and ">", making it impossible to inject HTML or script elements. There is no use case for such elements to be entered legitimately by the user in this application.

Secondly, all data that originally came from the user and is echoed into HTML via PHP goes through the PHP function htmlspecialchars, called from our function f_input_accept. This ensures the browser will render any HTML or script elements as text, rather than trying to execute them.

As described in the section Modal forms: API and AJAX, we also show user-inputted text via Javascript. This text will also only be shown after passing through a custom function which escapes HTML and script elements.
Expose internals The attacker tries to force an error in the application, in the hope of showing software versions and/or directory structures. We configure the server not to show errors (PHP config) or the directory structure or Apache version (Apache config).

We also ensure that a file containing phpinfo() is never left on the server.
Password attack The attacker attempts to access the web application by guessing or brute-forcing one of the user's passwords Brute-forcing is prevented using our Login Attempt system.

Guessing the password is made more difficult by our password format requirements contained in the function f_validate_password, but this is still a vulnerability. Users should be asked to use KeePass and should be reminded not to use the same password for more than one site.
Session hijacking The attacker manages to impersonate a valid user by gaining access to his authenticated session ID. This is a current vulnerability which is fixed by using SSL/TLS on all pages which require authentication (see Packet sniffing above).
SQL injection The user enters malicious SQL into a form field, and when this is sent to the database, the malicious code is executed. Firstly, we have a dedicated database user for the website which doesn't have direct access to any database tables.

Secondly, we use parameterized queries for almost all database interaction.

Thirdly, for the few occasions we can't use parameterized queries, we pass all user-entered data through the function f_input_query, which strips out characters which are needed for an SQL injection attempt.

Service accounts

Attack name Description Our defenses
Password attack The attacker tries to guess or brute force our service account passwords such as those for Dropbox, AWS or Gmail. The big companies have their own protection against brute force attempts, we don't need to worry about that.

But that still leaves a few guess attempts. The passwords for these services must be generated via Keepass so they are unguessable.


Attack name Description Our defenses
Insider attack Someone within the club decides to steal our data. The greatest liability is the data that we store for clients while working on their projects. Each client's data should be stored in its own area, separate from the common area, and access should only be granted to admins, and on an "as-needed" basis.

The club itself doesn't have much data that would be useful to steal. Passwords are hashed and no financial details are stored. The list of users and their email addresses might be useful to spammers. Direct database access should only be granted to admins, and then on an "as-needed" basis.

comments powered by Disqus