Bezpečnost ve webových aplikacích (English)

Z FI WIKI
Verze z 10. 11. 2013, 00:17; 232464@muni.cz (diskuse | příspěvky)

(rozdíl) ← Starší verze | zobrazit aktuální verzi (rozdíl) | Novější verze → (rozdíl)
Přejít na: navigace, hledání

(Security in Web Applications)

Authentication and Authorization

The access to Web applications must very often be limited to a specific group of users. This page discusses the ways in which you can achieve this.

When discussing access control, we use two important concepts:

  • Authentication (authentication English) - Proof of identity of an entity
  • Authorization (authorization in English) - the decision to permit access to certain resources

Example of life - when entering a building you must show ID, it proves I am Franta Novák and I have proven my identity. When entering into a top secret military facility the authorization fails, even though my identity is proven. A common mistake is to confuse authentication for authorization i.e. as if I let anyone whoever has an ID to enter.

Authentication for Web applications

There are many ways to perform authentication in Web applications:

  • HTTP BASIC - name and password
  • SSL client certificate
  • Filling in the username and password into a form
  • Shibboleth - Single-Sign-on (identity federation)
  • OpenID and OAuth
  • And the others (HTTP DIGEST, Kerberos, etc.)

Let's analyze the most frequent.

HTTP BASIC authentication

The oldest, and probably most common, is the authentication by using name and password at the HTTP protocol. It is performed in the way that when your browser tries to access a protected page, it will send the HTTP server response:

 HTTP/1.1 401 Authorization Required
 WWW-Authenticate: Basic realm = "secret area"
 ...

which returns to the browser window a view with the following look:

Prompt.PNG

and the username and password sent in the request header:

GET /chranene/ HTTP/1.1
Authorization: Basic bWFrdWI6bWFrdWJpaw==
...

in which the name and password can only be written using Base64, i.e. unencrypted. Therefore, it is necessary to use the HTTP Basic Authentication always over an encrypted channel, ie SSL.

The basic authentication can be set directly in the web application descriptor (web.xml), but you can set also it in a servlet or in a servlet filter.


Authentication with SSL certificates

Communication between the browser and the HTTP server can be encrypted using SSL (Secure Socket Layer). The server side must always authenticate the submission with a X509 digital certificate - client side may do so if the server requested.

When you establish a connection the server sends its X.509 certificate. The client checks the validity of the certificate by using the server's certificate public key. The client generates a symmetric encryption key to use to encrypt the communication.

The SSL server may require the client to establish a connection with your digital certificate signed by one of the Certification Authority that the server recognizes as credible. The browser then displays a prompt to the user to submit the certificate:

Cert.PNG

The client certificate authentication is best set with the Apache server, that you can use in a servlet container using mod_jk. In servlets, we obtain information about the submitted client certificate request using some standard attributes:

javax.servlet.request.cipher_suite
javax.servlet.request.key_size
javax.servlet.request.X509Certificate

or, if you send from Apache via mod_jk information about the variables with JkEnvVar, then the attributes are named

SSL_CLIENT_S_DN
SSL_CLIENT_M_SERIAL
SSL_CLIENT_CERT

Form-based authentication

The most commonly used method is to create an HTML form where the user must fill out name and password, and if correct, those are stored in the HTTPSession so that the user is authenticated. Again, it is necessary to ensure that all the connections are encrypted.

For the authentication of forms, a standardized method is to declare the support in in web.xml. This is called the Servlet API specification 'HTTP FORM'. However, it is good to know that this method is quite limited, and it is better to implement your own form and access protection using the servlet filter.

Shibboleth (Single Sign-on) - federated identity

Of all the mentioned technologies it is the newest. Users tend to have a lot of accounts on many servers and it is difficult to remember a different password for each,leading to use the same password everywhere. Using of a certificate is not a solution, as users must make some effort to obtain the certificate.

As a solution to these problems, there was the emergence of the idea of Identity Federation. Most users belong to an organization (school, employer , professional associations, etc. ) which has been assigned a name and password (or other authentication method ) to them. Organizations with legal contracts can create a federation in which they trust each other. Thus, the user always logs in with his home organization, that it provides the selected information (in the form of a document in a format called SAML) to Web sites of other organizations. Schematic diagram:

Federace.png

In the Czech Republic there has been a test federation between universities (provided by CESNET) since the summer of 2007. Since the beginning of 2009 it is in full operation under the name eduID.cz. Organizations with users operate with the Identity Provider (IdP) application for Tomcat, which is the only access to passwords and ensures their verification. In contrast, organizations providing services use the so-called Service Provider (SP) authentication module for the Web server.

The Masaryk University is involved in the project eduID.cz since the initial tests. The identity provider operates at the Department of Computer Science, with several Service Providers - one instance on this server Kore. You can try Shibboleth (single-sign-on) yourself by clicking "login via with muni.cz" at the top right.


OpenID and OAuth

OpenID is an open standard protocol for specifying authentication.

OAuth is an open standard protocol for specifying authorized access to the operations listed in some APIs, but it can also be used for authentication when the API has a function to obtain information about the user.

OpenID

OpenID allows you to login to any website using the account of another server , called identity provider (identity provider) . The user can either get just an identifier, or attributes such as firstname, lastname, email .

OpenID identity providers support Google , Seznam.cz, MojeID.cz .

To transfer attributes about the user, there are two different extensions of OpenID, called Attribute Exchange (AX) and Simple Registration (SREG) . It is necessary for each identity provider to find out which of them are supported, e.g. Google and MojeID use AX, Seznam.cz uses SREG.

Implementation for the Java library OpenID4Java.

OAuth

OAuth allows you to enable a particular service provider for a specific operation (of operations) to a service API.

OAuth supports Google, Facebook, Twitter.

The API and the set of its operations are specific to each service. e.g. Facebook allows you to enable reading basic personal data or other personal data, or allow the writing on the wall. Google allows you to grant access only to the calendar, only to documents, etc.

The library Spring Social provides a unified API to access various social networking sites using OAuth tied with Spring MVC. Writing a simple authentication via OAuth can be easy even with Servlet API and HTTPURLConnection classes, see e.g. [1].

OAuth supports not only service-based but allows also mobile applications (Android, iOS).

A popular tutorial for OAuth 1.0 is available at The OAuth 1.0 Guide.

Known Attacks

Cross-site scripting (XSS)

Cross-site scripting is an attack that tries to circumvent the same origin policy in browsers, and get access to data.

'Defense: escaping must be properly done. For users' input text, it needs to be escaped so that special characters are replaced. e.g. < is substituted with < - in java applications better using the tag '<c:out value="${hodnota}"/>.

Cross-site request forgery (XSRF)

Cross-site request forgery is a passive attack: the attacker sets a code on a page, which causes the invocation of an URL of some other server where the user may still be logged.

'Defense:' important events (such as money transfers) must be certified in the application by using randomly generated values.

Clickjacking

This attack consists in hiding the real action of the page by sovraimpressing another frame (also opacity levels in CSS can be used). The user is guided to click on a section of the page that apparently performs some action, while in background he is performing a different one.

'Defense:' It is possible to use the new X-Frame-Options X-Frame-Options that is supported by the majority of browsers. The principle consists in preventing framing within pages. Options that can be set are ​​DENY, SAMEORIGIN, or ALLOW-FROM origin, that - respectively - prevent framing completely, only from external sites, or allow framing only by the specified site.

Session hijacking

Session hijacking is an attack in which the attacker gets access to a cookie used to describe successfully authenticated user.

'Defense:' Session cookies must be labeled secure, i.e. they can only be sent over encrypted SSL connection. In the case of transmission of session ID via URL the defense is more complicated, requiring to prevent the leakage through the referer URL (links, images, ...) and Session fixation.

Phishing

Phishing is an active attack in which the attacker publishes his own website pages mimicking the original ones, tricking the users into providing their user credentials.

'Defense:' educate the users in control of the authentication server, use Extended Validation SSL Certificates

SQL Injection

SQL Injection attack is not just limited to web applications, but due to the fact that web applications are often accessible to the masses of users they must be well protected against it.

Defense: consistent use of PreparedStatement and its setXXX() methods to set values​​. Where it is not a value (the name of a column in the ORDER BY), check the input of regular expression for the expected value.