-
Notifications
You must be signed in to change notification settings - Fork 0
Security Issues
Following here
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.
Most privacy concerns will only be coming from the content that users post. Educating users on what content is safe to post is a potential deterrent.
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.
For more specifics, see here. XSS, or cross site scripting, is 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.
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.
For more specifics, see here. From Django: "SQL injection is a type of attack where a malicious user is able to execute arbitrary SQL code on a database. This can result in records being deleted or data leakage.". With Django, this is largely a non-issue as SQL queries follow a very rigid format, and the query's SQL codes are actually defined in a different way than query parameters. The only issue would be if Developers were to write raw SQL commands, which they can. When doing so, developers would have to be very careful in writing.
For more specifics, see here. From Django: "Clickjacking is a type of attack where a malicious site wraps another site in a frame. This attack can result in an unsuspecting user being tricked into performing unintended actions on the target site." With Django, this is largely a non-issue. Django already has middleware to protect against this; essentially it makes it impossible to render a site inside a frame.
Root users will only be admins. Admins will be required to undergo training on how to use the system and how to properly update items in the code without destroying precious data. Furthermore, the system is to undergo backups periodically to ensure that even if data were to be destroyed, there would be a storage of it to pull from. Within Django there are methods of running code whenever models are deleted; such methods could also be used to notify admins of an accidental wipe of data.