Clases de despido en la ley de productividad y competitividad laboral

Only four works were found that focus on server-side race conditions. They are discussed below. Conclusions regarding the impact of their research on our work are discussed at the end of the section:

• The work by Paleari et al. (2008) seems to be the first research in this di- rection. They note that concurrency is one of the oldest security problems, because it is both hard to detect and because"(..) a typical programmer does not conceive his web application as a multi-threaded or multi-process entity". A lot has changed in web development since this research was conducted, but these statements still hold. The research focuses on race conditions in the interactions between a multi-threaded web app and the underlying DataBase Management System (DBMS).

They test the following popular Content Management System (CMS): Joomla, Wordpress and phpBB. The test does not include the popular Drupal CMS. The test itself encompasses capturing the requests from the application to the database and forwarding these in parallel to the database. The parallel requests should result in race conditions at the database. They especially look for security relevant findings, and this resulted in the following insights.

In the applications that they tested, they were able to register multiple users with the same name, perform more login attempts, cast more votes, and send more messages than was officially allowed due to races in the logic that checked for these conditions. Obviously, having more login attempts makes brute forc- ing attacks easier, but the other findings are only a security issue when it re- sults in a (financial) advantage like multiple one-time bonuses, results in an unexpected state of the application or helps in certain privilege escalation or DoS attacks.

• The second work we would like to discuss is a section of the book by (Stuttard and Pinto, 2011, pp. 426-427). Chapter 11 in this book is about attacking the application logic of web apps and ends with a discussion of a number of previously executed attacks that were done by the authors. The 12th _example is discussed in our introductory chapter in section 1.1.2. This example ends with a number of steps that a tester or hacker can take in order to perform a black-box test for race conditions.

They state that this kind of test is not straightforward and that "It should be regarded as a specialised undertaking, probably necessary only in the most security-critical of applications"1. We agree that, currently, it is a specialised undertaking, but when a better testing methodology and supporting toolset is created, this issue should be partially alleviated. The authors then list several hacking steps that boil down to:

1. Functionality- Select web app parts with the most important functionality like the login, password change, or funds transfer.

2. Requests- Select a limited number of requests to perform one action within the functionality and define a means to verify that the attack is successful.

3. Attack - Select high-spec machines and send these requests in parallel on behalf of different users.

4. Evaluation - Evaluate the results and filter out the potentially the large number of false-positives as this load-test type of attack could result in a lot of non-related anomalies.

Together with tips and hacking steps found in other sources, we will use these steps as a start for our systematic methodology for testing race conditions in web apps (see section 4.2).

• The third research is executed by Zheng and Zhang (2012) who perform static analysis of the interaction between a web server and its external resources from a white-box perspective in order to find race conditions. They state that most other research only seems to focus on in-memory race conditions, but fail to also look at resource contention in external. The research explicitly refers back to the research by Paleari et al. discussed above and distanced itself from it in several ways. It is similar in that both look at calls from PHP scripts to external resources, but the work by Paleari et al. is dynamic in nature and 1_{In the remainder of this chapter, we will show that this issue is far more prevalent and has more}

therefore requires concrete database interaction traces to work with. It also does not look at the program semantics. This research converts the PHP code to C and has developed a "(..) context- and path-sensitive interprocedural static analysis to automatically detect atomicity violations on shared external resources in PHP code". They found 113 errors in real web applications, of which some are security issues with financial impact.

• The fourth research is executed by Billes et al. (2017) is about the automatic detection of race conditions in collaborative web applications like Google Docs. As these applications are meant to be used with multiple users at the same time, race conditions between updates to the same data are likely to occur and can result in diminished user experience. That is why they set out to cre- ate a black-box visual analysis tool that first learns potential behaviour from recorded user interactions and then replays these sequences to find conflicts automatically. They could successfully find several functional issues in col- laborative web applications. The approach seems similar to what Mutlu et al. (2014) have performed, but instead of replaying actions using recorded XHR requests, they record and replay user interaction using the Selenium Web- Driver. This test method is also comparable to how Adamsen et al. (2017b) try to find client-side race conditions.