internetteknologi 2 itnet2 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Internetteknologi 2 (ITNET2) PowerPoint Presentation
Download Presentation
Internetteknologi 2 (ITNET2)

Loading in 2 Seconds...

play fullscreen
1 / 55

Internetteknologi 2 (ITNET2) - PowerPoint PPT Presentation

  • Uploaded on

Internetteknologi 2 (ITNET2). Presentation 5: Security. 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)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Internetteknologi 2 (ITNET2)' - vesta

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
internetteknologi 2 itnet2

Internetteknologi 2 (ITNET2)

Presentation 5:


  • 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
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?
  • 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
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 (
  • 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
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 …
  • 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
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
  • 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
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
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
  • 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”)


Username/password or digital signature

  • 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!
  • 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
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
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
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 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
two main methods
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
enabling ssl
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
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
2) Configure Apache Tomcat
  • Edit <tomcat_home>\conf\server.xml
  • Uncomment the following

Production servers

operate standard

at port 443

<Connector port="8443"











keystoreFile="C:/Program Files/

Apache Software Foundation/Tomcat 5.5/tomcatkeystore.jks"

keystorePass="testtest“ />

example form based security
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 !

alternative realms
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 3 create a login page
Example: Step 3Create a Login Page



<title>Login Page for Examples</title>

<body bgcolor="white">

<form method="POST" action='<%= response.encodeURL("j_security_check") %>' >

<table border="0" cellspacing="5">


<th align="right">Username:</th>

<td align="left"><input type="text" name="j_username"></td>



<th align="right">Password:</th>

<td align="left"><input type="password" name="j_password"></td>



<td align="right"><input type="submit" value="Log In"></td>

<td align="left"><input type="reset"></td>






example step 4 create a failed login page error jsp
Example: Step 4Create a failed login page (error.jsp)



<title>Error Page For Examples</title>


<body bgcolor="white">

Invalid username and/or password, please try

<a href='<%= response.encodeURL("login.jsp") %>'>again</a>.



example access rules
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 6 result after logging in
Example: Step 6Result after Logging in

SSL at

port 8443

SSL at

port 8443

extending declarative security
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 security2
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


<display-name>Securing the Calender application</display-name>


<web-resource-name>Protected Area</web-resource-name>

<!-- Define the context-relative URL(s) to be protected -->







Protecting the Apache Tomcat

Calendar application

checking for ssl
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
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