eirikvaa / tdt4237-2019-group05 Goto Github PK

When a user registers, there are no restrictions on the passwords a user can have.Meaning that users may select very vulnerable password, such as a single letter.

Sessions have virtually no expiration (~70 years). Neither is the session invalidated on logout.

When accessing either a bash file or a python file that has been uploaded, the file will be executed. This allows for arbitrary code execution on the server. Which may allow root access to the server to privilege escalation on the server.

Neither login throttling, nor a lockout mechanism is implemented. Making it very simple for an attacker to perform brute force attacks on the login page.

The form for giving permissions for any task does not perform a CSRF check, meaning it is vulnerable to CSRF attacks.

The page is vulnerable to clickjacking. So, malicious sites can embed the page in an iframe and lure users into performing actions they would not normally due. Such as give permissions on their tasks to the attacker.

Users may open uploaded project files that they do not have permissions for, by enteringthe URL directly.

The delete functionality for a file does not check for permissions, which means that any user may delete any of the files uploaded to the page.

Lists of allowed_hosts is intended to be a white-list and including 0.0.0.0 means that any
host is accepted. Accepting any host is not recommend as this gives attackers the
opportunity to make Django generate and display URL’s to users on arbitrary domains.

Sessions are not renewed on login. In addition, the same session id is shared between all sessions for a single user. This means that, together with no session expiration, if an attacker gains access to the session of a user, the attacker will have permanent access to the user.

The login page is vulnerable to SQL injections. An attacker may for example login to user with username “admin” by entering admin’--in the username field.

All session keys for users are visible from the admin panel. If an attacker can get admin
access on the site, he can steal all session keys and get access to all other users. Remove
all information about sessions keys from site.

After the user has filled in the registration form in the web application, the web application will send an email to the user to let him/her click to verify the validity of the email address.

The application is running in debug mode, meaning that an attacker can gain valuable information from the stack traces shown when an internal server error occurs.

When users register, they need to choose answers of some security questions(Examples of security questions can be found at https://docs.whmcs.com/Security_Questions). The answers of the security question will be saved in the system. If a user forgets When users register, they need to choose answers of some security questions(Examples of security questions can be found at https://docs.whmcs.com/Security_Questions). The answers of the security question will be saved in the system. If a user forgets the password, the user can click the forget pass-word link. Then, the user needs to type in correct email address. If the email address is valid, his/her chosen security question will be displayed. Then, the user needs to fill in the answer of the security question. If the security question answer is correct, a randomly generated temporary password and a link for letting the user logging in using this password will be sent to theuser’s email address for logging in.the password, the user can click the forget password link. Then, the user needs to type in correct email address. If the email address is valid, his/her chosen security question will be displayed. Then, the user needs to fill in the answer of the security question. If the security question answer is correct, a randomly generated temporary password and a link for letting the user logging in using this password will be sent to the user’s email address for logging in.

The password hashing algorithm used on the server is severely insecure. It is both using MD5 and a static salt.

The page is running on Django 2.0.6, which is known to have vulnerabilities.

The header of each page leaks the password of the currently logged in user in a comment. Also, the form for giving permissions, leaks a list of all the users. This together with the SQL Injection, allows the attacker to login to all users.
Note: The server is also running over HTTP instead of HTTPS, which exposes information in-flight between the server and client. Since we are responsible for the hosting, this is not something you will have to fix.

Follow-up with the forget password function, when a user logs in using the temporary password, a web page will show to force the user resetting his/her password. The user needs to type in the temporary password, new password, and the new password again. If the temporary password is correct and the typed in and re-typed in password matches, the new password will be saved in the system for later logging in.

Exploitation of insufficient logging and monitoring is the bedrock of nearly every major
incident. Attackers rely on the lack of monitoring and timely response to achieve their
goals without being detected.
All group should add logging of failed login attempts

It is possible to perform a stored cross site scripting attack on the project description field.

It is possible for an attacker to leverage MIME sniffing to determine a different file type
and cause the execution of malicious script. For example, malicious file can be “translated”
by the browser as an image jpg. Thus, browser will execute it as an HTML and therefore
causing the execution of malicious script.