There is a new contentreviewitem property called isUrlAccessed which controls whether or not a submission in the queue (file) can be retrieved by Turnitin. Before granting access to the file resource (in BaseAssignmentService.getHttpAccess()), it checks this property and returns early if it is true.

After many, many iterations of testing and debugging, it seems that there's a race condition happening here.

The TII callback to retrieve the file happens very quickly, and sets the isUrlAccessed to true. Milliseconds later, the queue job continues on, and does some unrelated updates to the same contentReviewItem. Now, because the queue job is using the DAO to update the object, regardless of if it's explicitly setting the isUrlAccessed attribute or not, Hibernate will update this field to the default value.

So, TII gets the file, sets the isURLAccessed to true, then the queue job continues and sets it almost immediately back to false. In effect, this leaves the URLs to access these content review files open for anyone to access once more, as there is no authentication performed on these requests.

The solution to this, is marking the urlAccessed column as insert=true and update=false in the Hibernate mapping XML file. In this way, when creating a new contentReviewItem, the urlAccessed parameter will default to false, and any code updating this object via the DAO will reject any changes to this column.

Then, in the one and only place we want to set the urlAccessed value to true (after TII has called us back and retrieved the file), we call a method that runs some custom HQL to manually update the value to true for the given row.

We've also added some extra obfuscation to these URLs because they are not authenticated. Currently, the URL could technically be determined by an attacker (with a combination of sleuthing/inspecting elements and brute force), as it contains the site ID, the submission ID, and the (positive, sequential integer) ID of the content review item.

The extra protection we've implemented, is by appending the hash value of the contentId to the access URL. Due to the fact that the content ID is a combination of two additional, non-user facing UUIDs and the actual file name and extension of the file in question, it is near impossible for an attacker to determine this string and it's subsequent hash code. When the URL is accessed, it will first check to see that the hash codes match, and short circuit if not.

Lastly, we've modified the conditional logic around actually serving up the file. Previously, the file was only served if and only if the isUrlAccessed property was false. However, due to the calls to and from TII being asynchronous, we cannot safely assume that the status of the item will be either 1 or 2 by the time TII attempts to retrieve the file. Depending on timing, it could very well be one or the other (coupled with the fact that we've seen TII make multiple requests to get the same file), and we need to allow TII to get the file in both of these circumstances.

Therefore, we've determined that the file should be served in only the following circumstances:

• if the URL has not yet been accessed

• if the URL has been accessed, but the status is one of the following: 1 (not yet submitted), 2 (submitted, waiting for report), and 4 (submission error, will retry)

Of course, the hashing protection and validation happens prior to checking these conditions, serving as both another layer of obfuscation as well as a short circuit for the process.