Internetteknologi 2 (ITNET2)

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


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


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


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?


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 …


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


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


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)


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


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


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


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!


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


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


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


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


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


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


Programmatic Security


Form-Based Authentication(Declarative Security)


Form-Based Authentication(Continued)


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)


1) Generating SSL Keystore Certificate

• Run Java Keytool• Move resulting file to

Tomacat Home

keytool -genkey -alias tomcat -keyalg RSA -keystore tomcatkeystore.jks


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


Unknown Certificate


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 !


Example: Step 1


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)


Example: Step 2


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>


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>


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


Example: Step 5


Example: Step 5 (continued)


Example: Step 6


Example: Step 6Result after Logging in

SSL at port 8443

SSL at port 8443


Form-Based vs. BASICAuthentication


BASIC Authentication


BASIC Authentication(Continued)


Example


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><%

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

 <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


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


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

Internetteknologi 2 (ITNET2)

Documents

Transcript of Internetteknologi 2 (ITNET2)