Session and Security Management

1
Session and Security Management
2
HTTP Cookies
3
Cookies

• Cookies are a general mechanism that server-side
  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

4
Cookie Transportation
Web browser
Web server
5
Cookie Transportation
Web browser
Web server
An Example
6
Cookie Format

• A cookie in a response header
• Set-Cookie NAMEVALUE expiresDATE pathPATH
  domainDOMAIN_NAME secure
• Only the NAME field is required
• A cookie in a request header
• Cookie NAME1VALUE1 NAME2VALUE2
  NAME3VALUE3...
• This header contains all matching stored cookies

7
Cookie Properties

• NAMEVALUE the content of the cookie
• should not contain semi-colons, commas or
  white-spaces
• expiresDATE expiration date
• default is the session life time
• pathPATH the paths for which the cookie is
  valid
• matches every path that begins with PATH
• domainDOMAIN_NAME the cookies domain
• matches every domain that ends with DOMAIN_NAME
• secure send only through secure channels (i.e.,
  https)

8
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

9
Session Management
10
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

11
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?

12
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

13
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
• Session Cookies
• URL rewriting

14
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)

15
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)

16
Session Cookies
Servlet
id1
Web browser 1
Web server
17
Session Cookies
Servlet
id2
id1
Web browser 2
Web server
18
Session Cookies
Servlet
id2
id1
Web browser 1
Web server
19
Session Cookies
Servlet
id2
id1
Web browser 2
Web server
20
sessionId
list
21
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

22
URL Rewriting
Servlet
id1
Web browser
Web server
ltHTMLgt ltA HREFservletURLsessIDid1gt lt/HTML
gt
23
URL Rewriting
Servlet
id2
id1
Web browser 1
Web server
ltHTMLgt ltA HREFservletURLsessIDid1gt lt/HTMLgt
GET servletURLsessIDid1 HTTP/1.0
24
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

25
Configuring Sessions in Tomcat

• In Tomcat (and other Servlet containers), you can
  specify the session timeout (in minutes) in the
  application's web.xml
• If the timeout is 0 or negative, then sessions
  never end (on the server side)

26
Security Management in Web Applications
27
We all know this page...
28
Would we want all to know this page?
29
Problem

• 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?

30
Authentication Methods

• Several authentication methods are used
• Declarative Security
• HTTP-level mechanisms
• Basic authentication scheme
• Digest access authentication scheme
• Server-level mechanisms
• Programmatic Security

31
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 to a protected
  resource, it checks whether that request has the
  HTTP header
• Authorization Basic usernamepassword
• 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

32
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

33
Declarative Security BASIC
Realm A
/a/A.html
/a/B.jsp
Realm B
/b/C.css
E.xsl
/b/D.xml
F.xml
34
Declarative Security BASIC
Realm A
/a/A.html
/a/B.jsp
Realm B
/b/C.css
E.xsl
/b/D.xml
F.xml
35
Declarative Security BASIC
Realm A
/a/A.html
/a/B.jsp
Realm B
/b/C.css
E.xsl
/b/D.xml
F.xml
36
Declarative Security BASIC
Realm A
/a/A.html
/a/B.jsp
Realm B
/b/C.css
E.xsl
/b/D.xml
F.xml
37
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

38
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

39
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 MD5
• 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)

40
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

41
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

42
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

43
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

44
Authentication Management in Tomcat
45
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

46
Defining Users and Roles

• Create a database that stores users and roles
• A table that stores usernames and passwords
• A table that stores usernames and roles
• Tell Tomcat how to access your tables in the file
  TOMCAT_BASE/conf/server.xml
• Users and roles can be dynamically added to the
  database

47
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) )
48
In server.xml
ltRealm className"org.apache.catalina.rea
lm.JDBCRealm" driverName"oracle.jdbc.dri
ver.OracleDriver" connectionURL"jdbcora
clethinsnoopy/snoopy_at_sol41521stud"
userTable"users" userNameCol"username"
userCredCol"pass"
userRoleTable"users_roles"
roleNameCol"role"/gt
49
Static Users and Roles

• You can alternatively define a static set of
  users and roles in
• CATALINA_BASE/conf/tomcat-users.xml

lttomcat-usersgt ltrole rolename"members"/gt more
roles... ltuser username"snoopy"
password"snoopass" roles"members"/gt more
users... lt/tomcat-usersgt
50
Tomcat Manager

• The default resource of users is the file
  tomcat-users
• 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"

51
Defining Restrictions in web.xml

• ltsecurity-constraintgt
• ltweb-resource-collectiongt
• ltweb-resource-namegtrestricted
  onelt/web-resource-namegt
• lturl-patterngt/restricted1/lt/url-patterngt
• lt/web-resource-collectiongt
• ltweb-resource-collectiongt
• ltweb-resource-namegtrestricted
  twolt/web-resource-namegt
• lturl-patterngt/restricted2/lt/url-patterngt
• lt/web-resource-collectiongt

52
Defining Restrictions in web.xml

• ltauth-constraintgt
• ltrole-namegtmemberslt/role-namegt
• lt/auth-constraintgt
• lt/security-constraintgt
• ltlogin-configgt...lt/login-configgt
• ltsecurity-rolegt
• ltrole-namegtmemberslt/role-namegt
• lt/security-rolegt  

53
BASIC Authentication in Tomcat

• Add to the application's web.xml the login method
  (BASIC) and your chosen realm name

ltlogin-configgt ltauth-methodgtBASIClt/auth-method
gt     ltrealm-namegtDear Memberslt/realm-namegt lt/logi
n-configgt
54
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 its 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

55
Add to web.xml
ltlogin-configgt ltauth-methodgtFORMlt/auth-methodgt
ltform-login-configgt ltform-login-pagegt/adm
in/login.html lt/form-login-pagegt
ltform-error-pagegt/admin/login-error.html
lt/form-error-pagegt lt/form-login-configgt lt/login
-configgt
56
Create A Login Page

• lthtmlgt
• ltheadgtlttitlegtLog Inlt/titlegtlt/headgt
• ltbody style"background-coloryellow"gt
• lth2gtLog in for accessing this resource.lt/h2gt
• ltform action"j_security_check" method"post"gt
• ltpgtLogin ltinput type"text"
  name"j_username"/gtlt/pgt
• ltpgtPassword ltinput type"password"
• 
  name"j_password"/gtlt/pgt
• ltpgtltinput type"submit" value"Log In"/gtlt/pgt
• lt/formgt
• lt/bodygt
• lt/htmlgt

myApp/admin/login.html
57
Create A Login Page
myApp/admin/login-error.html

• lthtmlgt
• ltheadgt
• lttitlegtLogin Failurelt/titlegt
• lt/headgt
• ltbody style"background-coloryellow"gt
• lth1gtWrong username and
  password!lt/h1gt
• lt/bodygt
• lt/htmlgt

58
Important Disable the Servlet Invoker

• When protecting certain URLs, it still might be
  possible to bypass the authentication process
  because the URL of the Servlet invoker is not
  protected
• That is, a Servlet can be accessed by
  http//host/prefix/servlet/Name even if protected
  URLs are mapped to that Servlet
• For this reason (and others), it is OK to use the
  invoker while developing, but once the
  application is published the invoker should be
  disabled!

59
SSL Connections
60
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.

61
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

62
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

63
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

64
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

65
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

66
SSL in the Network Layers
Email Protocols
HTTP
SSL
TCP/IP
67
The SSL Handshake
1. Client gets the Server's certificate
Is this a good certificate?
Client
Server
68
The SSL Handshake
2. Client creates a master secret and shares it
with the server
Client
Server
69
The SSL Handshake
3. Client and server create symmetric session
keys from the master secret
Client
Server
70
The SSL Handshake
Data is transferred using the session keys
Client
Server
71
SSL Certificates

• To assure that the replier to 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 VeriSign, 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

72
The Server's Certificate
Public Key
Serial Number
Validity Period
Server's Name
Issuer's Name
Issuer's Digital Signature
73
An Example The Certificate of bankleumi.co.il
74
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?

75
SSL in Tomcat 5.0

• To use SSL connections in Tomcat 5.0, 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

76
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

77
Generating a Certificate (cont)

• From the command line, type the following
• keytool -genkey -alias tomcat -keyalg RSA
  -keystore keyfile

78
(No Transcript)
79
Enable the HTTPS Service

• Add the following to CATALINA_BASE/conf/server.xm
  l under the Service "catalina"
• Declare the redirection port for the HTTP
  Connector
• ltConnector port"8090" redirectPort"8443"/gt

80
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