S 5.160 Authentication to web servers
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: Administrator
In order to be able to determine the identity of users and to assign corresponding rights to the users, there are different mechanisms described in the sections below. Once a user authenticated successfully (for example by entering user name and password), a so-called session is assigned to him/her. A session is a session assigned to a user that describes an active connection established to the server. Sessions are necessary, since the protocol (HTTP) used for web applications is stateless. Each query to a web server is processed independently of all other queries received before. In order to nevertheless be able to display user-dependent states on websites (e.g. the login status of a user or the contents of a shopping basket), sessions are used.
A session is identified with the help of an unambiguous session ID. This session ID is transmitted to the client upon successful login and sent again during every subsequent query to the server. This enables the web server to determine that the query is in a certain context and to assign the query to a user.
Form-based authentication
The form-based authentication is a commonly used authentication method and is used for the majority of web applications. With this, the login data is transferred to the web application using a form. The user is then authenticated by the web application, which verifies whether the transferred login data corresponds to the stated user. The advantage of this kind of authentication is the seamless integration of the login function into a web application, since the entry of the login data is simply performed using the input fields of the web application. Since the authentication is performed by the web application, attempted logins may additionally be handled very flexibly (e.g. handling of failed login attempts, error messages). However, increased levels of flexibility also entail the problem of vulnerabilities in the implementation. For example, it must be ensured that the login data is transmitted using a secure connection.
Basic Access Authentication
HTTP Basic Access Authentication was specified within the framework of HTTP/1.0 in RFC 1945 and provides a simple authentication mechanism. However, the login procedure is not performed using the web application, but by the web server in this case. Here, the login data is sent only Base64-coded and in an unencrypted form, which is why this kind of authentication must only be used using secure communication. If the attacker is capable of listening in on the communication, he/she may reverse the coding and read user name and password in plain text. Basic Access Authentication offers protection on the directory level, since it is possible to define which user is allowed to use which access functions to which directories. This kind of authentication is supported by all commonly used web servers and browsers, but is deemed obsolete and is hardly used any more.
Digest Access Authentication
Digest Access Authentication is based on Basic Access Authentication, but was complemented by security functions. For example, only a corresponding MD5 checksum is transmitted instead of the login data. MD5 can no longer be considered secure for all fields of application. However, the collision detection option available with MD5 does not have any influence on the authentication, since random figures are used here. The random figure newly determined by the server during each authentication attempt is integrated into the MD5 checksum. This way, secure authentication can be guaranteed even using insecure channels. Digest Access Authentication is specified in RFC 2617.
Host-based authentication
During host-based authentication, the access rights are determined based on the IP address. This kind of authentication is susceptible for IP spoofing, however. In this case, an attacker falsifies the IP addresses of the network packets sent by him/her, resulting in the queries contained therein being executed using other access rights.
Certificates
Certificate-based authentication is based on a public key infrastructure. With this, the identity is verified using a certificate containing the public key of an entity (e.g. user) that must be signed by a certificate authority. The certificate authority is responsible for verifying the identity before signing the certificate. Normally, this is performed by a proprietary registration authority.
In most cases, a so-called two-factor procedure is used within the framework of certificate-based authentication. This means that not only the possession of the certificate, but also another factor, typically a password, is required in order to verify the identity. Depending on the field of application, the certificate may be stored to different media. Examples include tokens, chip cards, or software certificate memories.
Cookies
Normally, cookies are small text files storing information on HTTP sessions locally on the client side. These are sent during new queries to a web server in the HTTP header and therefore allow for the client to be recognised by the server. The server may use the cookie in order to determine the user sending a query.
In addition to an unambiguous ID, the cookie may also contain other information. An example includes the information as to the domain and the path a cookie is valid for. Since the sending of cookies is controlled by the browser, the browser is also responsible for the cookies only being accessible to the related domain, as defined by the server. Additionally, cookies may contain flags. If the httponly flag is set, it is no longer possible to read or modify the cookie using JavaScript.
With the help of cross-site scripting, it is possible to steal cookies from susceptible domains and to use these cookies to pretend to be another user to the web server. In this, an attacker implants code into the web application that is executed on the client of the user and transmits the desired cookie to the attacker in the background.