Presentation 5:
Security
Internetteknologi 2 (ITNET2)
Ingeniørhøjskolen i ÅrhusSlide 2
Agenda
– Plenum: your experience with security– Threats and Security Attacks– What is needed to provide secure solutions– Encryption and SSL– Security in J2EE Applications
• Declarative Security (Ex Configuration in XML files)
• “Semi-declarative Security”• Programmatic Security (Your code and application)
Examples are in J2EE (JSP/Servlets) but principles are the same on all server-side platforms
Ingeniørhøjskolen i ÅrhusSlide 3
Experience with Security
• To establish a picture of your knowledge – What kind of security issues do you know of?– How may these be solved?– What experience do you have in using these?
Security Attacks
Ingeniørhøjskolen i ÅrhusSlide 5
Motivation
• Many vital/secret data handled by distributed systems
• Loss of confidence: above effects may reduce confidence in systems.– And in the company (and the developer) who made the system!
• Legal issues – in DK there are strict rules for handling of personal data (Persondataloven) – Other legal issues – if you make a mistake …
• They will sue your ass off ;-)
Ingeniørhøjskolen i ÅrhusSlide 6
Why are Distributed Systems insecure?
• Distributed components rely on messages sent and received from network
• Public Networks are insecure!– Anyone can listen and capture data packages– Try downloading a sniffer (http://www.ethereal.com/)
• Is a client (e.g. a browser) secure?• Are users of calling clients really who they claim to
be?• Are the users allowed do all the possible actions?
Ingeniørhøjskolen i ÅrhusSlide 7
Effects of Insecurity
• Confidential Data may be stolen, e.g.:– corporate plans– new product designs– medical/financial records (e.g. Access bills....)
• Data may be altered, e.g.:– finances made to seem better than they are– results of tests, e.g. on drugs, altered– examination results amended (up or down)– OR worse – a nuclear power plant cooling control gets
turned off … or the new radar delivered from Terma hides North Korean fighter planes or rockets …
Ingeniørhøjskolen i ÅrhusSlide 8
Threats
• Categorisation of attacks (and goals of attacks) that may be made on system
• Four main areas (from Emmerich/Colouris):– leakage: information leaving system– tampering: unauthorised information altering– resource stealing: illegal use of resources– vandalism: disturbing correct system operation
• Used to specify what forms of attack the system is proof, or secure, against
Ingeniørhøjskolen i ÅrhusSlide 9
Methods of Attack
• Eavesdropping*: Obtaining message copies without authority (*to listen to a conversation without the speakers being aware of it)
• Masquerading: Using identity of another principle (eg user) without authority– Simply read the document, and steal the password
• Message tampering: Intercepting and altering messages (HTML/HTTP/SQL injection)
• Replaying: Storing messages and sending them later
Ingeniørhøjskolen i ÅrhusSlide 10
Infiltration
• Launch of attack requires access to the system– Launched by legitimate users– Launched after obtaining passwords of known users
• Aka “social engineering” – actually quite easy ;)
• Subtle ways of infiltration:– Viruses– Worms– Trojan horses– Exploits (exploiting some known weakness)
Ingeniørhøjskolen i ÅrhusSlide 11
What’s needed for secure requests 1?
• Separating public and private networks (firewalls)– Or Virtual Private Networks (VPN’s) – But many users will not be willing to download a VPN
client
• Establishing security association between client & server (authentication/authenticity) via e.g. public keys, digital signature, others
• Deciding whether principal may perform this operation (access control) – username/password and/or digital signature matched w. ACL
Ingeniørhøjskolen i ÅrhusSlide 12
What’s needed for secure requests 2?
• Making the principal accountable for having requested the operation (auditing) – tracking access of authenticated user
• Protecting request and response from eavesdropping in transit (encryption) via SSL
• Proving that you have delivered a particular service (non-repudiation) – tracking access of authenticated user
Ingeniørhøjskolen i ÅrhusSlide 13
Desirable Properties
• Desirable properties:– confidentiality– integrity– authenticity– access control– auditing– non-repudiation (Repudiation is something like “a refusal by a
government to acknowledge and honor a claim or obligation because it is considered to be invalid”)
SSL/TLS
Username/password or digital signature
Main Security Principle:Encryption by SSL
Ingeniørhøjskolen i ÅrhusSlide 15
Introduction
• Cryptography: encode message data so that it can only be understood by intended recipient
• Romans used it in military communication• Given knowledge of encryption algorithm, brute
force attempt: try every possible decoding until valid message is produced
• Computers are good at this!
Ingeniørhøjskolen i ÅrhusSlide 16
Encryption
• Encrypting data prevents unauthorised access and modification to the data (i.e. prevents eavesdropping and tampering)
• If encrypted data can only be decrypted with a matching key, this can be used to prove sender’s identity (i.e prevents masquerading)
• Likewise, it can be used to ensure that only intended recipients can use the data
• Two main ways: secret key & public key
Ingeniørhøjskolen i ÅrhusSlide 17
Using Secret Keys (Symmetric)
• One key is used to both encrypt and decrypt data• Must exchange keys through some secure,
trusted, non-network based means– As a disk via snail mail, or build into executable
• Sender encodes message using function and sends, knowing that only the holder of key (the intended recipient) can use it.
• Recipient decodes message and knows that only sender could have generated it
• Message can be captured but is of no use
Ingeniørhøjskolen i ÅrhusSlide 18
Public Keys (Asymmetric)
• Gives 'one-way' security • Two keys generated, one used with decryption
algorithm (private key) and one with encryption algorithm (public key)
• Generation of private key, given public key is computationally hard (hard to crack)
• Do not need secure key transmission mechanism for key distribution
Ingeniørhøjskolen i ÅrhusSlide 19
Using Public Keys
• Recipient generates key pair• Public key is published by trusted service• Sender gets public key, and uses this to encode
message• Receiver decodes message with private key• Replies can be encoded using sender’s public key
(actually a second key) from the trusted distribution service
• Message can be captured but is of no use
Ingeniørhøjskolen i ÅrhusSlide 20
Secure Socket Layer (SSL)
• Secure Transport between Browser and Web-Server– Solves the problem with thin clients – eg HTML
transfers
• Also used for object-oriented middleware• Based on RSA public key technology• Client generates secret session key• Client uses public key of server to encrypt session
key and transmit it to the server• Session key is used to encrypt any
communication between client and server
Security in J2EE ApplicationsJSP/Servlets
Ingeniørhøjskolen i ÅrhusSlide 22
Two Main Methods
• Declarative Security (Container managed)– Security is handled by container– Easy to implement– Less flexible– FORM-based Authentication– BASIC Authentication
• Programmatic Security (Application managed)– Security is handled by programmer– Harder to implement– More flexible
• Both should use SSL encryption
Declarative Security
Ingeniørhøjskolen i ÅrhusSlide 24
Declarative Security
Ingeniørhøjskolen i ÅrhusSlide 25
Programmatic Security
Ingeniørhøjskolen i ÅrhusSlide 26
Form-Based Authentication(Declarative Security)
Ingeniørhøjskolen i ÅrhusSlide 27
Form-Based Authentication(Continued)
Ingeniørhøjskolen i ÅrhusSlide 28
Form-Based Authentication(Continued)
Ingeniørhøjskolen i ÅrhusSlide 29
Form-Based Authentication(Continued)
Ingeniørhøjskolen i ÅrhusSlide 30
Form-Based Authentication(Continued)
Ingeniørhøjskolen i ÅrhusSlide 31
Form-Based Authentication(Continued)
Ingeniørhøjskolen i ÅrhusSlide 32
Enabling SSL
• Some servers have default SSL support• Apache Tomcat must first be configured• Two steps
– 1) Generate a private key (using Java Keytool)– 2) Configure Apache Tomcat (or other Application
Server)
Ingeniørhøjskolen i ÅrhusSlide 33
1) Generating SSL Keystore Certificate
• Run Java Keytool• Move resulting file to
Tomacat Home
keytool -genkey -alias tomcat -keyalg RSA -keystore tomcatkeystore.jks
Ingeniørhøjskolen i ÅrhusSlide 34
2) Configure Apache Tomcat
• Edit <tomcat_home>\conf\server.xml• Uncomment the following
<Connector port="8443" maxThreads="150“minSpareThreads="25" maxSpareThreads="75“enableLookups="false" disableUploadTimeout="true"acceptCount="100" scheme="https" secure="true"clientAuth="false" sslProtocol="TLS" keystoreFile="C:/Program Files/
Apache Software Foundation/Tomcat 5.5/tomcatkeystore.jks"
keystorePass="testtest“ />
Production servers operate standard
at port 443
Ingeniørhøjskolen i ÅrhusSlide 35
Unknown Certificate
Ingeniørhøjskolen i ÅrhusSlide 36
Example: Form-Based Security
Find example in Apache Tomcat:C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\jsp-examples\security\protected
Must enable SSL for the Application Server at first !
Ingeniørhøjskolen i ÅrhusSlide 37
Example: Step 1
Ingeniørhøjskolen i ÅrhusSlide 38
Alternative Realms
• You may use other sources to obtain a list of users and passwords
• These are called ”Realms”• Available Realms:
– MemoryRealms (fetches from tomcat-users.xml)– JDBCRealm & DataSourceRealm (from a DB)– JNDIRealm (from a Java Naming and Directory
Interface – including LDAP)– JAASRealm (for other sources, including Microsoft
Active Direectory)
Ingeniørhøjskolen i ÅrhusSlide 39
Example: Step 2
Ingeniørhøjskolen i ÅrhusSlide 40
Example: Step 3Create a Login Page
<html><head><title>Login Page for Examples</title><body bgcolor="white"><form method="POST" action='<%= response.encodeURL("j_security_check") %>' > <table border="0" cellspacing="5"> <tr> <th align="right">Username:</th> <td align="left"><input type="text" name="j_username"></td> </tr> <tr> <th align="right">Password:</th> <td align="left"><input type="password" name="j_password"></td> </tr> <tr> <td align="right"><input type="submit" value="Log In"></td> <td align="left"><input type="reset"></td> </tr> </table></form></body></html>
Ingeniørhøjskolen i ÅrhusSlide 41
Example: Step 4Create a failed login page (error.jsp)
<html><head><title>Error Page For Examples</title></head><body bgcolor="white">Invalid username and/or password, please try<a href='<%= response.encodeURL("login.jsp") %>'>again</a>.</body></html>
Ingeniørhøjskolen i ÅrhusSlide 42
Example: Access Rules
In the Apache Tomcat security example we only have one role for one mapping (index.jsp), and only using SSL (the CONFIDENTIAL setting). You may however make any combination of mappings you might like
Ingeniørhøjskolen i ÅrhusSlide 43
Example: Step 5
Ingeniørhøjskolen i ÅrhusSlide 44
Example: Step 5 (continued)
Ingeniørhøjskolen i ÅrhusSlide 45
Example: Step 6
Ingeniørhøjskolen i ÅrhusSlide 46
Example: Step 6Result after Logging in
SSL at port 8443
SSL at port 8443
Ingeniørhøjskolen i ÅrhusSlide 47
Form-Based vs. BASICAuthentication
Ingeniørhøjskolen i ÅrhusSlide 48
BASIC Authentication
Ingeniørhøjskolen i ÅrhusSlide 49
BASIC Authentication(Continued)
Ingeniørhøjskolen i ÅrhusSlide 50
Example
Ingeniørhøjskolen i ÅrhusSlide 51
Extending Declarative Security
• Basic Declarative is ‘all or nothing’• Possible to get user data from security system• From HTTPServletRequest
– isUserInRole– getRemoteUser– getUserPrincipal
You are logged in as remote user <b><%= request.getRemoteUser() %></b>in session <b><%= session.getId() %></b><br><br>
<% if (request.getUserPrincipal() != null) {%> Your user principal name is <b><%= request.getUserPrincipal().getName() %></b><br><br><%
Programmatic Security
Ingeniørhøjskolen i ÅrhusSlide 53
Programmatic Security
• You may implement the security yourself• Using session variables (or Cookies as Nordfalk)
– You might use a ”User” or ”Login” object attached to the session
• Similar to Form-based authentification– But NOTHING is automated– Must invent own role system
• If you want to use SSL with Apache Tomcat <security-constraint> <display-name>Securing the Calender application</display-name> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected --> <url-pattern>/cal/*</url-pattern> </web-resource-collection>
<user-data-constraint><transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint> </security-constraint>
Protecting the Apache Tomcat Calendar application
Ingeniørhøjskolen i ÅrhusSlide 54
Checking for SSL
• Checking for SSL– If programmer is uncertain of server SSL capabilities– request.getScheme (returns http or https)– requeset.isSecure (returns true or false)
• Quality of SSL encoding (number of bits)– request.getAttribute(“javax.servlet.request.key_size”);
• Looking up encryption algorithm– request.getAttribute(“javax.servlet.cipher_suite”);
• Redirecting if no SSL – or quality too low– respone.sendRedirect
• Only when administrator and programmers cannot work together
Ingeniørhøjskolen i ÅrhusSlide 55
Benefits of Programmatic Security
• Advantages– Provides independence of server-specific components– More flexible than Declarative security– Permits custom security system (alternative to
username / password)– No need for web.xml entries (depending on server ssl)
• Disadvantages– Must write own security framework– No way to protect e.g. an entire folder of JSP files, all
files must contain security checks (or web.xml must be used to force all data through a Front Controller)
– Tedious and error-prone work