1

47

The security of a session management mechanism depends on how well a web application handle the related session tokens. Session tokens must be created in such a way they are unpredictable, and they should not have an internal structure nor meaning (even obfuscated). The best session tokens are long sequences of random bytes generated by a secure random number generator, and associated to server-side session data. All data about the current application state should be stored at the server side, and the session token should act only as a key to access it.

48

An alternative to random session tokens are authenticated session tokens. With authenticated session tokens, the current state of the application is entirely stored at the client side (e.g., with a cookie) in a form that protects its integrity, typically by means of message authentication codes (MACs) computed with a symmetric key known only by the server. Every time the server receives a request containing cookies, it verifies their integrity before using them. Of course, if the symmetric key(s) are not well-protected, then all the security is compromised. This technique makes the server more lightweight because it outsources all the state information to the clients. However, it does not allow the server to perform data mining on the application states, which could be a valuable source of information.

49

After session tokens (either random or authenticated) have been created, they must remain confidential during their entire lifecycle. Indeed, if an attacker steals somehow the token of an ongoing session of a legitimate user, then she can inject requests on the same session, thus impersonating the user. This is called session hijacking. First of all, tokens should be transmitted only over confidential channels, such as HTTPS. If HTTP cookies are used to transmit tokens, they should be flagged with the “secure” attribute. The “secure” attribute tells the browser that the cookie should be transmitted only over HTTPS. In this way, even if the website contains non-HTTPS pages (usually static resources like help pages) the session token does to risk being compromised.

50

Session tokens should never be transmitted in URLs, because this is unsafe for the same reasons explained before for passwords: URLs appear on screen, on browser history, on server logs, etc. In addition to these reasons, sending session tokens in URLs exposes the users to session fixation attacks. In a session fixation the attacker induces a legitimate user to follow a particular URL (e.g., by sending an email with a link inside) containing an untrusted session token, which has been previously released by the server to the attacker herself. In this way, the attacker obtains the same final effect of a session hijacking.

51

The application should implement a logout functionality, with which the users can delete all the server-side session information and invalidate the session token. However, users must not be supposed to explicitly log out at every session. Thus, sessions should also automatically expire after some inactivity period (e.g., 10 minutes).

52

53

An access control vulnerability occurs when an application lets users do something thatthey are not authorized to do. This typically includes accessing unauthorized resources(files, data, etc.) or performing unauthorized actions (creating users, modifyingdatabases, etc.). Access control vulnerabilities are critical since they compromise all the protection guaranteed by authentication and session management mechanisms. Theyare the number #1 vulnerability in the OWASP top ten 2021.

54

Broadly speaking, access controls can be devided into three categories: vertical accesscontrols, horizontal access controls, and context-dependent access controls. Vertical access controls allow users of different type to access different functionalities. Usersare divided in types, each of which with different access privileges. A classic example iswhen an application distinguishes between normal users and administrators, and it letsonly administrators to create new users. A violation of a vertical access control is a vertical privilege escalation. Horizontal access controls allow different users of the same type to access different functionalities. An example is when a webmailapplication lets each user read his own mails, but it prevents other users to do so. Another example is when an online banking application lets each costumer to operate on his own account, but it prevents other costumers to do so. A violation of a horizontal access control is a horizontal privilege escalation. Context-dependent accesscontrol allows the same user to access different functionalities depending on the current state of the application (the context). A classic example is when a multi-stage process of an application prevents users from skipping stages or accessing stages out of the prescribed order. A violation of a context-dependent access control is a business logic exploitation.

55

An obvious access control vulnerability occurs when access control decisions are takenon the basis of client-side variables that can be tampered with. A common example are access controls based on the HTTP «Referer» header, which can be easily modified.

56

Access rules based on the location of the user are another case of vulnerable client-based access control. If the location is inferred from client-side geolocation (for example the GPS receiver of smartphones), then location-spoofing applications can easily circumvent the control. Otherwise, if the location is inferred from the IP addressof the client, an attacker can circumvent it by means of proxy servers in the requiredlocation or VPNs that terminate in the required location.

57

Another common case of access control vulnerability takes place when criticalfunctionalities and resources can be accessed by anyone knowing their URL. The false assumption that an URL cannot be discovered if not explicitly linked is very prevalentamong web developers. However, URLs should never have the status of secrets, for several reasons. First of all, they are displayed on screen, and they appear in browser histories and in the logs of web servers and proxy servers. Moreover, they are oftenbookmarked by users and included in emails, and they cannot be changed periodicallylike secrets should be.

58

Sometimes, applications use a function to make users access to specific functionalitiesor resources, and they accept the identifier of the resource to access as an URL or POST parameter. For example, an application may use the following URL to display a document belonging to a specific user:www.example.com/view_document.php?document_id=63869240Of course, the application is vulnerable because the document identifier appears in the URL. However, even in the case the document identifer were sent via a POST parameter, the application would not be safe yet. The problem is that anyone whoknows the document identifier has access to the document itself, and typicallydocument identifiers are not long unpredictable sequences, neither they are periodically changed.

59

Some applications rely on the underlying web server to enforce access controls. The server-level access control is usually configured through a set of policy rules, whichallow or deny access based on (at least) three criteria: the HTTP request method (GET, POST, etc.), the URL path, and the user role. This solution can be effective for simpleweb applications, where only vertical and horizontal access controls are needed. Context-dependent access controls are more difficult to implement, because theystrictly depend on the application’s state, which is unknown to the underying web server.

60

The best approach is to implement the access controls by means of server-side code (e.g. PHP) basing on server-side variables, which allows for the best security and flexibility. However, since server-side code is fragmented in multiple pages, there is the risk that different pages apply inconsistent access control policies, thus for exampledenying a resource to be accessed from page1.php but allowing it from page2.php.

61

The best practice to enforce access control in complex web applications is to use a centralized component for all the authorization decisions (policy decision point, PDP). Every sensible resource or functionality must be provided by users via functions, and these functions must first query the central access control decisor before releasing the resource/functionality. The approach based on policy decision point increases the clarity and the maintainability of the access control mechanism, thus minimizing the error probability.

62

The simplest example of policy decision point is a PHP function that accepts the username and the requested resource/functionality as input, and returns whether the access is granted or not. Every other PHP page call this function at the beginning.

63

If static files need to be protected, they should be accessed only indirectly by means of a dynamic document-providing function which queries the policy decision pointbeforehand. One solution to do that is to use the «X-Sendfile» header.

64