Session and Security Management HTTP Cookies Cookies Cookies
- Slides: 79
Session and Security Management
HTTP Cookies
Cookies • Cookies are a mechanism that Web applications can use to both store and retrieve long-term information on the client side • Servers send cookies in the HTTP response and browsers are expected to save and to send the cookie back to the Server, whenever they make additional requests from the Server
Cookie Transportation request put cookie. . . response Web browser Web server
Cookie Transportation request Cookie: . . . response Web browser Web server An Example
Cookie Format • A cookie in a response header: Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure - Only the NAME field is required • A cookie in a request header: Cookie: NAME 1=VALUE 1; NAME 2=VALUE 2; NAME 3=VALUE 3. . . - This header contains all matching stored cookies
Cookie Properties • NAME=VALUE: the content of the cookie - should not contain semi-colons, commas or white-spaces • expires=DATE: expiration date - default is the session life time • path=PATH: the paths for which the cookie is valid - matches every path that begins with PATH • domain=DOMAIN_NAME: the cookie’s domain - matches every domain that ends with DOMAIN_NAME • secure: send only through secure channels (i. e. , https)
Notes about Cookies • A response may contain multiple cookies • A Cookie overrides previous cookies with the same path and name • If no path and domain are given, then they are assumed to be those of the requested URL • The Cookie header of a request contains all mappings that match the requested URL • A server can delete a cookie by sending a new one with the same path and name, but with expiry date in the past
Session Management
HTTP is Stateless • HTTP is a stateless protocol - Individual requests are treated independently - Without external support, one cannot tell whether an HTTP request is part of a continuing interaction between the client and the server • BUT some Web applications have states! - Online stores that maintain a shopping cart - Portals that remember your name and preferences
HTTP Sessions • The solution: Client and Server transfer some unique data in the course of a session • A session captures the notion of a continuous interaction between a server and a client - For example, a series of requests and responses between IE and Tomcat with short intervals between them • End users should be oblivious to session management • Session management should be efficient - Is it reasonable to send the whole shopping cart on every request to Amazon. com?
Session Supporting Servers • A server that supports sessions holds session-specific data in an internal data structure (session object) - For example, the content of the shopping cart • On the first request, the server initializes the session object and sends to the client a unique identifier for this object • During the session, the client attaches this identifier to every request to the server
Session Management Methods • How is the session key shared between the client and the server? • We will discuss two methods that Servlet containers (i. e. , Tomcat) support: 1. Session Cookies 2. URL rewriting
Session Cookies • In the response to the first request of a session, the server puts a cookie, which contains a session identifier • When the client sends subsequent requests, it also sends the cookie • The client sends the cookie as long as the requests are within its session bound (e. g. , the same browser process) • The server treats the cookie as a valid identifier as long as the requests are within its session bound (e. g. , a short time period passed since the last request)
Session Cookies • Session cookies are simply a special kind of cookies • The time boundary of session cookies is based on the session and not on an explicit date - This is the default expiration time • Actual session data is kept on the server (while the session cookie holds only an identifier of the session)
Session Cookies request id 1 Web browser 1 request Servlet put cookie id 1 response Create Session Web server
Session Cookies request id 2 Web browser 2 request put cookie id 2 response Servlet id 2 id 1 response Create Session Web server
Session Cookies request Cookie: id 1 Web browser 1 Servlet id 2 response id 1 Web server response Session read/write
Session Cookies request Cookie: id 2 Web browser 2 Servlet id 2 response id 1 Web server response Session read/write
session. Id list
URL Rewriting • Web browsers may refuse to save cookies - Can you think of reasons? • Therefore, some servers (like Servlet containers) support session management through URL rewriting • Instead of passing the session identifier in a cookie, the identifier is concatenated to the request URL • All links in a page should contain the session id - Hence, these links are dynamically created • Session management is thus oblivious to users
URL Rewriting request Servlet response Web browser id 1 response Create Session Web server <html>… <a href="servlet. URL; sess. ID=id 1"> …</html>
URL Rewriting request (no cookie) Servlet id 2 response Web browser 1 id 1 Web server response Session read/write <html>… <a href ="servlet. URL; sess. ID=id 1"> GET servlet. URL; sess. ID=id HTTP/1. 0 1 …</html>
Session Duration A session ends in either one of the following cases: • The server invalidates the session - Required explicitly, e. g. , a user logs out, or - The session was inactive for a long time • The client stops cooperating - Session cookies have expired, e. g. , the browser runs in a new process - External links are used instead of rewritten ones
Configuring Sessions in Tomcat • In Tomcat (and other Servlet containers), you can specify the session timeout (in minutes) in the application's web. xml <web-app> web. xml <session-config> <session-timeout>10</session-timeout> </session-config> </web-app> • If the timeout is 0 or negative, then sessions never end (on the server side)
Security Management in Web Applications
We all know this page. . .
Would we want all to know this page?
Problem Formulation • Want to restrict access to certain Web pages • Must answer the following questions - Which pages should be restricted? - Who should access restricted pages? - How should users be authenticated? - Should authentication data be encrypted?
Authentication Methods • Several authentication methods are used: • Declarative Security - HTTP-level mechanisms • Basic authentication scheme • Digest access authentication scheme - Server-level mechanisms • Programmatic Security
HTTP Basic Mechanism • In the basic authentication scheme of HTTP, the user's name and password need to be sent with each request for a protected resource • When the server gets a request for a protected resource, it checks whether that request has the HTTP header Authorization: Basic username: password • If the name and password are accepted by the server (i. e. , are those of a user that has the privilege to get the page), then the requested page is returned
HTTP Basic Mechanism • If the request does not have the authorization header or the name and password are not accepted, then the server replies with 401 (unauthorized) • An 401 response can have the header WWW-Authenticate: Basic realm="realm-name" • That is, "in order to get this resource, you will have to authenticate using the basic method" - Tell the user to supply authentication for pages in realm-name
Declarative Security: BASIC Realm A /a/A. html /a/B. jsp OK + Content GET E. xsl Realm B /b/C. css /b/D. xml E. xsl F. xml
Declarative Security: BASIC Realm A /a/A. html /a/B. jsp 401 + Basic realm="A" GET /a/B. jsp Realm B /b/C. css /b/D. xml E. xsl F. xml
Declarative Security: BASIC Realm A /a/A. html /a/B. jsp OK + Content GET /a/B. jsp + user: pass Realm B /b/C. css /b/D. xml E. xsl F. xml
Declarative Security: BASIC Realm A /a/A. html /a/B. jsp OK + Content GET /a/A. html + user: pass Realm B /b/C. css /b/D. xml E. xsl F. xml
Browser Cooperation • Throughout the session, the browser stores the username and password and automatically sends the authorization header in either one of the following cases: - The requested resource is under the directory of the originally authenticated resource - The browser received 401 from the Web server and the WWW-Authenticate header has the same realm as the previous protected resource
Digest Access Scheme • The most serious security flaw in the basic scheme is that the name and password are sent unencrypted, and hence everyone on the network path can read it • If an attacker snoops a request with basic authentication, she can access to the whole protection space of the resource • The digest access authentication scheme solves many of the flaws of the basic schemes, such as the one above
Digest Operation • Like the basic, the digest scheme requires that authentication data is sent with each request for a protected resource • However, passwords are not sent in clear text • The idea is to use a one-way hash, such as MD 5 • A one-way hash H is a mapping of strings that has the following properties: - It is "easy" to compute H(x), given the input x - It is "hard" to compute x, given the mapping H(x)
Digest Operation (cont) • In the digest scheme, instead of sending the password x in clear text, the client sends H(y) • y is the concatenation of the user name, the password, an opaque generated by the server, the request URI, and more • A server that gets digested authentication data repeats the same encryption process and compares its output with the given H(y) • More details can be found in RFC 2617
Server-Level Authentication • A Web server can use its own authentication mechanisms rather than those of HTTP • Typically, server-level mechanisms act as follows - The server requires authentication by redirecting the client to a special HTML form - If authentication succeeds, then the server stores the username in the corresponding session object • Note that the browser and the HTTP headers are oblivious to server-level authentication
Programmatic Security • In declarative security, a page is either accessible to a user or is not • But what if we wanted a page to include some data that will only be shown to privileged users? - E. g. , the grades of the user • In programmatic security, we enhance security checks in dynamic pages (e. g. , JSP) • Using this approach, an application can generate different contents for different users
Declarative-Security Advantages and Disadvantages • Advantage: Application programs (i. e. , JSP and Servlets) do not have to do anything special • Advantage: Security holes due to bugs are less probable • Disadvantage: Server-specific process • Disadvantage: All or nothing security - users can or cannot see the page - sometimes, what we really want is for the page content to be dependent on the user
Authentication Management in Tomcat
Declarative Security in Tomcat To apply declarative security in Tomcat, we have to do the following: - Define roles and users (i. e. , usernames and passwords) - Define the restricted pages and the roles that can access them - Define the authentication method that is used in the Web application
Defining Users and Roles 1. Create a database that stores users and roles • A table that stores usernames and passwords • A table that stores usernames and roles 2. Tell Tomcat how to access your tables in the file TOMCAT_BASE/conf/server. xml 3. Users and roles can be dynamically added to the database
An Example create table users ( username varchar(30) not null primary key, pass varchar(30) not null ); create table users_roles ( username varchar(30) not null, role varchar(30) not null, primary key (username, role), foreign key (username) references users(username) );
In server. xml <Realm class. Name="org. apache. catalina. realm. JDBCRealm" driver. Name="oracle. jdbc. driver. Oracle. Driver" connection. URL="jdbc: oracle: thin: snoopy/snp@sol 4: 1521: stud" user. Table="users" user. Name. Col="username" user. Cred. Col="pass" user. Role. Table="users_roles" role. Name. Col="role"/>
Static Users and Roles You can alternatively define a static set of users and roles in $CATALINA_BASE/conf/tomcat-users. xml <tomcat-users> <rolename="members"/> [more roles. . . ] <username="snoopy" password="snoopass" roles="members"/> [more users. . . ] </tomcat-users>
Tomcat Manager • The default resource of users is the file tomcatusers • If you use database users, then you need to add a a manager for Tomcat to your tables - Otherwise, you (and Eclipse) will not be able to log into the manager application • A manager is a user that belongs to the role "manager"
Defining Restrictions in web. xml <security-constraint> <web-resource-collection> <web-resource-name>restricted one</web-resource-name> <url-pattern>/restricted 1/*</url-pattern> </web-resource-collection> <web-resource-collection> <web-resource-name>restricted two</web-resource-name> <url-pattern>/restricted 2/*</url-pattern> </web-resource-collection>
Defining Restrictions in web. xml <auth-constraint> <role-name>members</role-name> </auth-constraint> </security-constraint> <login-config>. . . </login-config> <security-role> <role-name>members</role-name> </security-role>
BASIC Authentication in Tomcat Add to the application's web. xml the login method (BASIC) and your chosen realm name <login-config> <auth-method>BASIC</auth-method> <realm-name>Dear Members</realm-name> </login-config>
FORM-Based Authentication in Tomcat • Tomcat provides a built-in form-based authentication • In the first request to a restricted page, the server forwards the request to a login page • Using the form in the login page, the user submits login and password to a special URL of the server, and the latter stores the information in the session object • On subsequent requests, the server checks the session to see if it contains suitable authentication, and if so the requested page is returned
Add to web. xml <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/admin/login. html </form-login-page> <form-error-page>/admin/login-error. html </form-error-page> </form-login-config> </login-config>
Create A Login Page <html> <head><title>Log In</title></head> <body style="background-color: yellow"> <h 2>Log in for accessing this resource. </h 2> <form action="j_security_check" method="post"> <p>Login: <input type="text" name="j_username"/></p> <p>Password: <input type="password" name="j_password"/></p> <p><input type="submit" value="Log In"/></p> </form> </body> </html> my. App/admin/login. html
Create A Login Page my. App/admin/login-error. html <html> <head> <title>Login Failure</title> </head> <body style="background-color: yellow"> <h 1>Wrong username and password!</h 1> </body> </html> `
SSL Connections
Security on the Internet • The Internet is used to transmit sensitive data from clients to servers and vice-versa - User passwords - Credit card numbers - Private client data on remote servers (e. g. , Banks) • However, data packets are read by several computers on the way from the client to the server (and vice-versa) - Routers, proxies, etc.
Security on the Internet (cont) • For secure communication, the following should be provided: - Only the server can read the client requests - Only the client can read the server's responses - Only the client can send requests on behalf of itself - Only the server can send responses on behalf of itself • In short, no one should be able to interfere in the interaction, either by reading the transferred data or by impersonating one of the sides
Symmetric and Asymmetric Keys • Data can be encrypted and decrypted using keys, which are simply large numbers • Symmetric keys: the same key is used for both encoding and decoding of the message • Asymmetric keys: one key is used to encode the message, and another is used to decode it • It is considered practically impossible to decode a message without knowing the decoding key
The RSA Cryptography System • RSA was developed in 1977 by Ron Rivest, Adi Shamir and Leonard Adleman • It is the based on the asymmetric key mechanism: - Each participant has a private key and a public key - The public key is known to all and the private key is kept in secret within its owner - Asymmetric keys: the public key is the encoding key and the private key is the decoding key
Secure Connection: A Naive Approach • Consider the following protocol: - Server and Client send their public keys to each other - Data is encrypted using the public key of the receiver • What is wrong with this protocol? - Encryption methods (public keys) are known to everyone - everyone can impersonate the participants - A participant cannot tell whether its received key was indeed sent by the other participant
SSL Connections • The SSL (Secure Socket Layer) protocol is used to manage security of message transmission on the Internet • Data encryption and decryption is based on symmetric and asymmetric keys • The HTTPS (HTTP over SSL) protocol is actually the HTTP protocol above SSL transportation
SSL in the Network Layers HTTP Email Protocols SSL TCP/IP
The SSL Handshake 1. Client gets the Server's certificate Is this a good certificate? hello + SSL settings Client SSL Settings + Certificate Server
The SSL Handshake 2. Client creates a master secret and shares it with the server Client Server
The SSL Handshake 3. Client and server create symmetric session keys from the master secret Client Server
The SSL Handshake Data is transferred using the session keys (Http Request) Client (Http Response) Server
SSL Certificates • To assure that the replier of the first request is the server, the server sends a certificate • The certificate contains both the server's name and its public key • The certificate is issued by a Certificate Authority (CA), which is known to the client in advance - For example: Veri. Sign, Thawte, RSA Secure Server, etc. • CA signs the certificate using a digital signature, which the client can verify using a method similar to the private-public key method
The Server's Certificate Public Key Serial Number Validity Period Server's Name Issuer's Digital Signature
An Example: The Certificate of bankleumi. co. il
Authentication via SSL • If the server needs to assure the client's identity, the first interaction after the SSL handshake will typically be a client authentication • Client authentication is done using the regular (e. g. , HTTP) authentication mechanisms • What is the difference, though?
SSL in Tomcat 5. 5 • To use SSL connections in Tomcat 5. 5, we need to do the following: - Acquire a certificate - Enable the HTTPs service that listens to a designated port - Declare the pages that require SSL connections
Generating a Certificate • Acquiring a certificate from a known CA costs money • Instead, we will generate our own certificate • Naturally, the browser will not recognize the CA as a known one and will therefore alert the user
Generating a Certificate (cont) From the command line, type the following: keytool -genkey -alias tomcat -keyalg RSA -keystore keyfile
Enable the HTTPS Service • Add the following to $CATALINA_BASE/conf/server. xml under the Service "catalina": <Connector port="8443" scheme="https" secure="true" ssl. Protocol="TLS" keystore. File="keyfile" keystore. Pass="keypass"/> server. xml • Declare the redirection port for the HTTP Connector: <Connector port="8090" redirect. Port="8443"/>
Declare Secured Pages • In the application's web. xml, add the following element under the security constraint for which you want SSL to be used <user-data-constraint> web. xml <transport-guarantee> CONFIDENTIAL </transport-guarantee> </user-data-constraint>
- Php cookie
- Private securty
- Wireless security in cryptography
- E commerce security policy
- Http //mbs.meb.gov.tr/ http //www.alantercihleri.com
- Http //pelatihan tik.ung.ac.id
- Balabit psm
- Session tracking in asp.net
- Osi security model
- Guide to network security
- Visa international security model in information security
- Electronic mail security in network security
- What is nstissc security model
- Building security software
- Security guide to network security fundamentals
- Security guide to network security fundamentals
- Oreo cookies and plate tectonics
- Cookies frames and frame busting
- 6 types of cookies and examples
- Browser security model
- Oreo cookies and plate tectonics answers
- Security analysis and portfolio management project
- Security analysis and portfolio management project
- Chapter 9 information management and security
- Csam cybersecurity assessment and management
- Importance of security analysis and portfolio management
- Risk in security analysis and portfolio management
- Pyramid levels of management
- Management pyramid
- Top level management
- Mole cookies chemistry
- Please dont eat my cookie
- Syn cookies
- Refrigerator cookies contain a high proportion of fat
- Same origin policy cookies
- Is baking cookies a physical change
- Dxn biscuit
- Types of cookies texture
- Objective of cookies
- Cookie mixing methods
- Abc smart cookie
- Let's make some cookies
- Tahap akhir penyusunan laporan keuangan mikita cookies
- Oreo cookies plate tectonics
- Oreo cookies plate tectonics
- Document onreadystatechange
- Cite at least 2 examples of shortened and unshortened cakes
- Activar cookies explorer
- Header manipulation: cookies
- Think twice code once meaning
- Income elasticity of demand formula
- Sessions without cookies
- Rolled cookies definition
- Algorithm recipe example
- Bostongirlbakes
- Salsa cookies
- Four brothers share 5 cookies equally
- Dxn madhuram cookies
- Salsa cookies
- Rolled cookies are made from a stiff dough
- Session 0 windows
- Welcome to the new session
- Session
- Skill 22 listen for answers in order
- Team norming session
- 6 session name
- Session title
- Stateful session bean life cycle
- Session break even
- To the principal
- Ergonomics session
- Practical session meaning
- Practical session definition
- Definition of session in php
- What is the value of the staff-session cookie?
- Sample agenda for mentor meeting
- How to conduct jad sessions
- Interactive session poster
- Sample minutes of learning action cell session
- Ece 329