Security Issues

Following here

Identify sensitive information kept by your software. Explain how you plan to protect it.

User’s names will be kept with their profile, as well as an email and a password. Passwords are very sensitive information as many users may use the same password for multiple different accounts they use. The passwords will be ran through a one way algorithm and be stored with some “salt” so that attackers will not be able to easily get the stored password if they get access into the database. Django and Knox have shown to be strong protectors of passwords and tokens via their hashing methods, so no issues are expected here.

Other sensitive information would only be that information that a user decides to post, such as datasets, comments, or posts on datasets. While users will be allowed to remove any data created by themselves, users will be advised to always be sure that they do not post anything sensitive information regarding themselves. Furthermore, if another user maliciously posts sensitive information regarding a user, users could flag the perpetrator and admins could remove their post or block them.

Identify possible attack vectors, that is, ways malicious users could try to use your software to escalate their privileges. This includes root access to your server, access to other user's sensitive information (say via XSS attacks), root access to your database, etc. Explain protection plan.

XSS, or cross site scripting, are a way of injecting scripts into websites to exploit flaws in security or otherwise run malicious code for a user. Django already has built-in methods of preventing XSS attacks, see here. Essentially, Django automatically escapes HTML to prevent basic attacks. However, it is up to programmers to provide security for more advanced attack methods. Developers of Delta will always run backend checks to ensure that user data is formatted in a correct way, and that it is not malicious. This involves both restricting what users can input, and checking that what was inputted is safe. Another method is to use the HttpOnly flag to allow access of cookies only to the server, thus disabling any possible method of obtaining cookie information by an outside user. This is done by adding SESSION_COOKIE_HTTPONLY = True to your Django settings.py file.

Cross Site Request Forgery For more specifics, see here. From Django: "CSRF attacks allow a malicious user to execute actions using the credentials of another user without that user’s knowledge or consent.". Django has preset methods of avoiding these attacks, such as by providing a csrf_token in your HTML forms. You can learn more about their method here. With Django, this is largely not an issue unless a developer were to use csrf_exempt in a view, in which case the developer themself would have to be very careful about what operations are performed in that view.