I noticed that many of the servlets do not perform checks that either the user is an admin, has access to the project they are updating, or are even logged in at all. This means that the data stored in OpenDF will not be secure, as anyone who can access the server through HTTP can retrieve any data returned through these unauthenticated endpoints.
As an example, I can query the URL /api/project/54 without being logged in, and it will return the name, status and description of the project.
The endpoint to list all projects required authentication, but the project ID is sequential and easy to predict, so it doesn't take many HTTP calls to retrieve information for all projects.
Response from unauthenticated api call (/api/project/54):
<project>
<createdDate>2016-01-17T14:37:01Z</createdDate>
<description>This is the first project</description>
<idProject>54</idProject>
<name>First project</name>
<status>1</status>
</project>
As another example, you can also list all investigators assigned to a project without any authentication.
Making a HTTP GET request to /api/project/54/investigators returns:
This even returns the investigator's password hashes (which would have been in plaintext before I modified it to hash passwords with bcrypt), which can be attacked to retrieve the original password (for example using a dictionary attack with common passwords).
If the attacker breaks the password hash they would have full and persistent access to an investigator's account if broken, even after adding authentication to the endpoint if their password didn't change.
I noticed that many of the servlets do not perform checks that either the user is an admin, has access to the project they are updating, or are even logged in at all. This means that the data stored in OpenDF will not be secure, as anyone who can access the server through HTTP can retrieve any data returned through these unauthenticated endpoints.
As an example, I can query the URL /api/project/54 without being logged in, and it will return the name, status and description of the project. The endpoint to list all projects required authentication, but the project ID is sequential and easy to predict, so it doesn't take many HTTP calls to retrieve information for all projects.
Response from unauthenticated api call (/api/project/54):
As another example, you can also list all investigators assigned to a project without any authentication.
Making a HTTP GET request to /api/project/54/investigators returns:
This even returns the investigator's password hashes (which would have been in plaintext before I modified it to hash passwords with bcrypt), which can be attacked to retrieve the original password (for example using a dictionary attack with common passwords). If the attacker breaks the password hash they would have full and persistent access to an investigator's account if broken, even after adding authentication to the endpoint if their password didn't change.