Java secure coding guidelines

Writing secure code is hard.

The following checklist contains at least some pointer of what to keep in mind. Note that this does not include web development checks. Please check the OWASP Application Security Verification Standard Project for more information on that.


  • Not validating input
  • Code has unnecessary permissions
  • Misusing public static variables
  • Ignoring changes to superclasses
  • Assuming exceptions are harmless
  • Beliving space of integers is unbounded
  • Trust user input to obey invariants
  • Beliving a constructor exception destroys the object
  • Beliving deserialisation in unrelated to constructors

0. Fundamentals

  • Prefer obviously no flaws to no obvious flaws
  • Design API’s to avoid security concern (i.e. final classes)
  • Avoid duplication
  • Restrict privileges (policy files,
  • Establish trust boundaries
  • Minimize number of permissions checks (single point of access)
  • Encapsulate methods, fields and classes to coherent sets of behaviour

1. Denial of Service

  • Beware of activities that may use dispropportionate resources
    • Image processing
    • Complex object graphs
    • Zip bombs
    • Billion laughs attack
    • Parsing and processing complex grammars
    • Deserialisation processing anomalies
  • Release sources in all cases
  • Resource limit checks should not suffer from integer overflow

2. Confidential information

  • Purge sensitive information from exceptions
  • Do not log highly sensitive information
  • Purge highly sensitive information after use
    • Do not depend on garbage collection
    • Keep information local
    • Use char[] to clear traces

3. Injection and inclusion

  • Generate valid formatting
  • Avoid dynamic SQL
  • XML and HTML generation requires care
  • Avoid untrusted data on command line
  • Restrict XML inclusion
  • Care with files
  • Disable HTML display in Swing components
  • Take care of interpreting untrusted code

4. Accessibility and extensibility

  • Limit accessibility of classes, methods and fields
  • Limit accessibility of packages
  • Isolate unrelated code
  • Limit exposure of classloader instances
  • Limit extensibility of classes and methods
  • Understand how a superclass modifications affects subclass behaviour
  • Prefer composition insted of inheritance

5. Input validation

  • Validate inputs
  • Validate output from untrusted objects as input
  • Define wrapper arounds native methods

6. Mutability

  • Prefer immatable value types
  • Create copies of mutable output values
  • Create safe copies of mutable and subclassable input values
  • Support copy functionality for a mutable class
  • Do not trust identy equality when overridable
  • Treat passing input to untrust object as output
  • Treat output from untrust object as input
  • Define wrapper methods around modifiable internal state
  • Make public static fields final
  • Ensure public static final values are constants
  • Make classes final
  • Do not expose mutable statics
  • Static variables are global across a JRE

7. Object construction

  • Avoid exposing constructors of sensitive classes
  • Prevent unauthorized construction of sensitive classes
  • Defend against partially initialized instances of non-final classes
    • Throwing an exception from a constructor does not precent a partially constructed instance from being acquired
    • Attacker can override finalize() to obtain object
    • Constructors that call into outside code often naivelt propagate exceptions
  • Leaking this enables the same attack as if the constructor directly thre the exception
  • Prevent constructors from calling into methods tht can be overridden
  • Defend agains cloning of non-final classes
  • Throw exception BEFORE super() to destroy object

8. Serialisation and deserialisation

  • Avoid serialisation for security-sensitive classes
  • Guard data during serialisation
  • View serialisation the same as object construction
  • Duplicate SecurityManager checks during serialisation and deserialisation
  • Understand security permissions given to serialisation and deserialisation
  • Validate the data

9. Access control

  • Understand how permissions are checked
  • Beware of callback methods
  • Safely invoke AccesssController.doPrivileged
  • Know to restrict privileges through AccesssController.doPrivileged
  • Be careful caching results
  • Understand the context transfer
  • Understand how thread constructors transfer context
  • Safely invoke standard API’s that bypass SecurityManager checkes depending on the callers class loaer
  • Safely invoke standard API’s that perform tasks using the callers class loader instance
  • Be aware of standard API’s that perform Java language access checks against the caller
  • Be aware of java.lang.reflext.Method.invoke is ignored for checking the caller

AWS Overview

This is an overview of the Amazon Web Services most common components and some information about the AWS security model.

Infrastructure and Services

  1. Regions and availability zones
  2. Foundation services
  3. Platform services

1. Infrastructure


  • Regions are split into Availability zones
  • Availability zones can have multiple data centers

Edge locations

  • Instead of using the data centers data can be cached in edge locations
  • Used as CDN

2. Foundation services

  • Compute (EC2, Lambda, Auto-scaling)
  • Networking (Load-balancing, Route53, VPC)
  • Storage (S3, Block storage, glacies, EFS)

3. Platform services

  • Databases (DynamoDB, Relational DBs, Redshift)
  • Analytics (Kinesis, EMR, Data pipeline)
  • Deployment (Elastic beanstalk, CodeDeploy)
  • Mobile (Cognito, SNS)

AWS Elastic Compute Cloud (EC2)

  • Infrastructure as a Service (IaaS)
  • Spins up virtual machines in the cloud
  • Custom VM’s
  • Fully manages infrastructure
  • Fast provisioning
  • Elastic scaling
  • Pre-built images or bring your own
  • Configurable network
  • Use security groups to open/close ports

Amazon Machine Images (AMI)

  • Different images available
  • Configures OS and Root Volume
  • Public images available in AMI repo
  • AMI defines EBS backend (most common, flexible) or instance backend (faster and restricted)
  • AMI marketplace includes pre-build images with popular configurations

Storage options

  1. Root volume configuration
  2. Instance backend vs EBS backend
  3. Lifecycle of an instance

Root volume configuration

Defines where should OS be stored

Instance stored backed

Fast IO Drive directly connected to the instance Ephemereal storage Cannot be stopped

EBS stored backend

Slower IO Persistant storage Can be stopped


Advanced features

  1. Machine types with different optimisations (cpu/memory/storage/gpu etc.)
  2. Instance metadata (info on system) and user data (scripts can be launched on startup). NOT SECURE!
  3. Pricing models

AWS Simple Storage Service (S3)

  • Online HTTPS accessible storage
  • Built for unstructured binary data (files)
  • Highly scalable, durable, limitless


  • Access via SOAP/REST/Web/shell
  • Unlimited number of objects (each up to 5TB)
  • Secure with client-side or AWS provided server-side encryption
  • Bucket and object level access logs for auditing and compliance


  1. Architecture
  2. Buckets and Object
  3. Security options

1. Architecture

2. Buckets and Object

  • Top level containers for data (Objects)
  • Exist in gobal namespace
  • Created in a region
  • Cannot be nested
  • Usage/Charges can be aggregated by Bucket
  • Discrete data files betwenn 0-5 TB
  • Can be versioned
  • Bucket + Object + Version can map to unique URL

3. Security options

  • Access control at Bucket and Object
  • ACL’s
  • Identity and Access management policies
  • Bucket and Object policies can be defined with Access Policy Language (json)
  • Encrypt at rest with AES-256 or/and BYO and encrypt before sending

Advanced features

  1. Object Versioning
  2. Object Storage Classes
  3. Lifecycle Management

1. Object Versioning

  • Versioning set at bucket level
  • Existing objects have “null” version
  • New objects are assigned new version id
  • All versions are retained… even after delete

2. Object Storage Classes

  • Set at object level
  • Standard, Infrequently Accessed, Glacier, Reduced Redundancy
  • Different pricing, durability, and availablity

3. Lifecycle Management

  • Can delete old versions of files after some specified time
  • Can automatically move objects between storage classes
  • Configured with xml

Elastic Block Store (EBS)

  • Virtual hard drives in the cloud
  • Create volumes during EC2 creation or independently
  • SSD or Magnetic available
  • 1GB to 16TB available
  • Take snapshot into S3 at anytime
  • Use for root volumes, databases, application data
  • Pay per provision rather then usage

S3 comparasion

Virtual Private Cloud (VPC)

  • Private, isolated, virtual network
  • Create logically isolated subntes
  • Resolve ip adress ranges and assign to resources
  • Remotely connect to on-pre network with VPN
  • Supports both public and private networks
  • Available per Availability Zone

Security inside a VPC

  • Use network ACL’s and IAM Security Groups to controll access
  • Security groups control inbound and outbound traffic at intance level
  • Network ACL control inbound and outbound traffic at subnet level
  • Use a NAT gateway instance to allow access from private network to WAN
  • Setup route tables, firewalls, gateways

AWS Shared Responsibility Model

Defines who is responsible for what. Security in the cloud is up to user. Security of the cloud is handled by Amazon.

  1. Shared responsibility
  2. Physical security
  3. Hardware, software, network

EC2 Example

  • Amazon controls physical security
  • The user controls patching, firewall, security groups of the instance

S3 Example

  • Amazon controls patching and firewalls
  • The user controls access to filesm encryption, transport etc

2. Physical security

  • Non-descript, undisclosed locations
  • 24/7 security staff
  • Two factor auth for entry
  • Continual monitoring, logging and auditing

3. Hardware, software and network security

  • Automated change control process
  • Physical acces requires authorization with frequent renewal
  • Bastion servers act as gateways for privileged users
  • Network bboundary devices monitor and audit access
  • Unusual or abnormal activity monitoring of application usage, intrusion etc.

Regulatory compliance

  • PCI
  • ISO 27001
  • Many many more…




Defines the element as a grid container and establishes a new grid formatting context for its contents.

Grid-template-columns, grid-template-rows

Defines the columns and rows of the grid with a space-separated list of values.


Defines a grid template by referencing the names of the grid areas which are specified with the grid-area property. Repeating the name of a grid area causes the content to span those cells. A period signifies an empty cell.

Grid-column-gap, grid-row-gap

Specifies the size of the grid lines. You can think of it like setting the width of the gutters between the columns/rows.


A shorthand for grid-column-gap + grid-row-gap.


Aligns the content inside a grid item along the column axis (as opposed to align-items which aligns along the row axis).


Aligns the content inside a grid item along the row axis (as opposed to justify-items which aligns along the column axis).


This property aligns the grid along the column axis (as opposed to align-content which aligns the grid along the row axis).


This property aligns the grid along the row axis (as opposed to justify-content which aligns the grid along the column axis).

Grid-auto-columns, Grid-auto-rows

Specifies the size of any auto-generated grid tracks (aka implicit grid tracks).


This property controls how the auto-placement algorithm works. Any items not explicitly given a grid-row and grid-column will be auto aligned.

Child styles

Grid-column-start, grid-column-end, grid-row-start, grid-row-end

Determines a grid item’s location within the grid by referring to specific grid lines. Can use names specified in grid-template-columns and grid-template-rows.

Grid-column, grid-row

Shorthand for grid-column-start + grid-column-end, and grid-row-start + grid-row-end, respectively.


Gives an item a name so that it can be referenced by a template created with the grid-template-areas property. Alternatively, this property can be used as an even shorter shorthand for grid-row-start + grid-column-start + grid-row-end + grid-column-end.


Aligns the content inside a grid item along the column axis (as opposed to align-self which aligns along the row axis).


Aligns the content inside a grid item along the row axis (as opposed to justify-self which aligns along the column axis).





See the Pen Demo Flexbox 3 by CSS-Tricks (@css-tricks) on CodePen.

Container styles


This defines a flex container.


This establishes the main-axis.


Allow the items to wrap as needed.


This is a shorthand flex-direction and flex-wrap properties. Default is row nowrap.


This defines the alignment along the main axis.


This defines the default behaviour for how flex items are laid out along the cross axis.


This aligns a flex container’s lines within when there is extra space in the cross-axis, similar to how justify-content aligns individual items within the main-axis.

Child styles


This controls the order in which they appear in the flex container.


This defines the ability for a flex item to grow if necessary.


This defines the ability for a flex item to shrink .


This defines the default size of an element before the remaining space is distributed.


Shorthand for flex-grow, flex-shrink and flex-basis.


This allows the default alignment (or the one specified by align-items) to be overridden for individual flex items.

ISO 27001 – The big picture

The ISO27001 protects Confidentiality, Integrity and Availability (CIA) of information. This is a quick overview of what it covers and how the process works.


4 main areas

  • Clauses 0-3 General definitions and content
  • Clauses 4-10 ISMS mandatory compliance
  • Annex A Technical controls
  • Bibliography

Clauses 4-10

7 clauses relating to the nature and operation of the ISMS.

4 – Context of the organisation

  • Boundaries of ISMS and its scope
  • Makes sure you understand the organisation
  • Makes sure you understand interested parties
  • States that the organisation shall implement a information security management system

5 – Leadership

  • Support from leadership
  • Documented information security policy that is communicated properly
  • Define and assign responsibilities for the policies

6 – Planning

  • Determine risk and opportunities
  • How to apply risk assessment process
  • How to identify and analyse risk
  • How to treat those risks
  • How to set and reach security objectives

7 – Support

  • Ensure enough support is available for the information security management system
  • Ensure organisation has adequate resources, competence and awareness
  • Requirements for documentation and how it can be controlled and updated

8 – Operation

  • Operating the ISMS processes
  • Operating risk assessments
  • Operating risk treatment

9 – Performance evaluation

  • Evaluate the effectiveness of the ISMS
  • Monitoring and measuring and analysing the performance
  • Handles management reviews

10 – Improvement

  • ISMS should be continuous process

Annex A

  • Lists control objectives and domains used in ISMS
  • 114 controls in total


  • Set scope as early as possible
  • Applies to process, data, people, places, activities
  • Consider internal and external factors
  • Consider interested parties
  • Consider relationship between activities in your and other organisations


  • Business activities, data
  • Location specific data (production/test in different place)
  • Channel specific transactions
  • Specific products/services
  • What’s important from customer point of view

Risk assessment

Key part of ISMS. Repeatable method for risk assessment.

  • Criteria for accepting risk (appetite)
  • Identifying risks
  • Analyzing risks
  • Evaluating risks

Statement of applicability

Contains a list of controls necessary to treat identified risks.

  • Go through all 114 controls
  • Justify inclusion of controls
  • Justify exclusion of controls
  • Whether implemented or not

Required documents

16 mandatory documents

  • Procedures
  • Policies

7 mandatory records

  • Internal audit records
  • Correct action records

Case study Background

Globomantics is an online web service that allows a user to fill in their personal info and request a brochure from a company for some specific service.

  • 25 staff in total, IT team of 4
  • 2 developer, 1dba, 1 sysadmin
  • Want to be 27001 as customers ar financial services and they capture PII


Brochure request

  • Requester web site
  • Requester database
  • Mailing labels

New client onboarding

  • Configure new client and campaign

Statement of applicability

  • Tailor ISO 27001 to your business
  • Go through all 114 controls
  • List include/exclude information in columns

Certification lifecycle

  1. Start with scope
  2. Risk assessment, Statement of applicability, Internal audit, Management review, Mandatory documents
  3. State 1 audit with external auditor (all should be done)
  4. Stage 2 audit with external auditor (more strict)
  5. Recommended for certification
  6. Audit findings

Toolset and support

Tool support

  • File share (no versioning or history)
  • Templates and toolkits (rapid generation, might not align to organisation needs)
  • Document management system (VCS, Sharepoint)
  • Risk management and governance system

Organisational support

  • Human resources
  • Facilities
  • Training
  • IT operations
  • Software development
  • Business stakeholders

3rd party support

  • Gap analysis prior to Stage 1 audit to find issues
  • Other external help

Crypto fundamentals


One-Time Pad

  • Start with random sequence of letters
  • Write message without spaces and punctuation
  • Add numbers mod 26

  • Unbreakable if truly random

  • Different keys may give different resulting messages


  • Toss of coin generates 1 bit of entropy
  • Toss coing 8 times -> 8 bits of entropy -> 8 bits of storage to record outcome
  • Using OTP in takes log2(26) = 4.7 bits of information to record one letter
  • In OTP with 1000 letters we get 4700 bits of entropy
  • If truly random and only used once we get maximun entropy
  • Entropy does not increase witout adding more randomness


  • Much weaker then OTP (though still hard to break!)
  • Used interconnecting rotors applied in order
  • Rotors rotated with each keystroke (central rotor stepped twice to prevent consecutive patterns)
  • Also used a plug board to be able to swap letters in a fourth mapping
  • Same machine could be used to encrypt and decrypt but this prevented an output letter from ever being the same as the input


  • One mapping represents multiple different offsets

  • Entropy of 26 letters in OTP: 4.7*26 = 122.2

  • Entropy of 26 letters in Enigma rotor: 4.7 bits (internal wiring is constant)

  • Usage of reflector for decryption reduces entropy from log(26) to log(25) = 4.6 bits

  • Usage of double stepping central rotor also decreased entropy from 262626=17576 to 262526=16900

  • Same initial rotor settings used for a full day
  • No repeated initial rotor settings in a month
  • Key was encrypted twice in message and prepended (generated pattern)
  • Same message sent twice with different encryption (play cipher texts agains each other)
  • Plugboard configuration did not change during day so it was possible to combine intercepts to guess configuration

Diffie-Hellman key exchange

  • Whitfield Diffie and Martin Hellman (assisted by Raplh Merkle)
  • Key agreement and generation can be done over an untrusted channel

  • 2048 bit is smallest prime considered secure (616 digits)

  • Number of water molecules on earth (46 digits)

  • Very vulnerable to MitM since a MitM can send different values to Alice and Bob


  • Entropy is critical
  • Scrambling does not increase entropy
  • OTP can be proven secure but are hard to use
  • Patterns can be exploited
  • Weakest link is the human operator


  • Comes in 3 flavours to create a crypto system
    • Symmetric – Encrypts and decrypts
    • Asymmetric – Encrypts and decrypts
    • Hash Functions – Verifies authenticity
  • Relationship between key and ciphertext is called Confusion
    • Small change in key -> large change in ciphertext
    • XOR not sufficient; one-to-one
    • Key schedule gives us a large change
  • Relationship between message and ciphertext is called Diffusion
    • Diffuse the information so that small change in message -> large change in ciphertext
    • Hides patterns within message


  • Uses same key to encrypt and decrypt

Block ciphers

  • Block ciphers used to make it possible to use shorter key then message
  • Typical block size is 16 bytes
  • Operates in rounds where part of key (Round Key) is applied on block with some other operations
  • After some number of rounds, we end up with cipher text
Round Key
  • Derived from key using a key schedule
  • Key Schedule is an algorithm that can Shift, XOR, Multiply and perform other operations on original key
Electronic Code Book (ECB)
  • Encrypt blocks induvidually
  • Easy to crack since we get a lot of patterns and repeated information
Cipher Block Chaining (CBC)
  • XOR’s next adjacent block with previous block
  • First block is XOR’d with an Initialization Vector (IV) same size as block
  • Diffuses information
  • Makes it possible to encrypt message of arbitrary length when having fixed length key

Data Encryption Standard (DES)

  • Key length 64 bits using 8 bits for parity check -> 56 bit key
  • Has theoritical issues but key length is also much to short
  • Used in 3DES where DES runs 3 times with 3 different keys -> key length 168 bits

Advanced Encryption Standard

  • Uses Rijndael as encryption algorithm
  • 128, 192 or 256 bit keys
  • Block size 16 bytes organize din 4×4 matrix


  1. Uses key expansion to confuse the key and create a round key
    • Shift orignal key then;
    • XOR then;
    • Multiply
  2. XOR block with Round Key
  3. Substitution using S-Box
    • Essentially a lookup table with 256 entries where each byte is substituted
  4. Shift rows
    • Move top to bottom
  5. Mix columns to further confuse the key
    • Rotate the bytes in each row with a different number
    • First row is not rotated
    • Second row with one byte
    • Third row with two bytes
    • Fourth row with three bytes

Cryptanalysis – Why is Enigma weaker then AES?

  • Engima

    • 47.1 bits in plugboard
    • 14.1 bits in rotors
    • Total: 61.2 bits
    • No memory -> No diffusion
    • Predictable key exchanges -> little confusion
  • DES

    • 56 bits of entropy
    • CBC and IV -> Good diffusion
    • Rounds -> Good confusion
  • AES

    • 128-256 bits of entropy
    • CBC and IV -> Good diffusion
    • Rounds -> Good confusion


  • English text has about 0.6 – 1.3 bits of information per character
  • Compressed ASCII can be compressed to about 40% (although theoretical limit is 7.5 to 16%!)
  • Squeezes out redundancy and preserves information

Encryption vs Compression

  • Encryption masks patterns and adds information
  • Compression after encryption os not effective
  • Compression uses redundancy and removes compression
  • Compress before encrypting -> More diffusion

Error Correction

  • Operation
    • Checksums
    • Discover errors
    • Correct errors
  • Combined with encryption
    • Adds redundancy
    • Makes ciphertext easier to crack
  • Only error check at time of transmission, not encryption!
    • Does not weaken encryption but still protects the message


  1. Compress
  2. Encrypt
  3. Transmit and correct


  • Diffie-Hellman first example of asymetric algorithm
  • Needs proof of identity (public key)

  • Find numbers to use for exponents using RSA

Elliptic Curve Cryptography (ECC)

  • A non-vertical line intersecting 2 points will also intersect a third
  • No line intersects at more than 3 points
  • The curve is symmetrical
  • Basic operation

  • Easy to find An if A0, A1 and n are given

  • Very difficult to find n if A0, A1, An are given

  • Example function: y^2 = x^3 + 3x + 5 mod p where x and y are integers and p is prime

    • Private key: n
    • Public key: An
  • Can use shorter keys then RSA (163-359 bits)

Hash functions

  • One way functions that can digest a message
  • Encrypt message digest with private key -> signed message
  • Receipient computes same hash and decrypts signature to verify

CRC 32

  • Produces a 32-bit hash based on Cyclic Redundancy Check
  • Uses a 33 bit polynomial and stores 32 bits of it
  • Easily reversible since intended for error detection, not suitable for signatures
  • A MitM can reverse the algorithm and replace the original message with an evil message with same hash

Cryptographically Strong Hash Functions

  • Uses bit shifts, modulus addition and XOR in rounds to diffuse message
  • Makes it difficult to reverse the process
  • Very popular but very weak
  • No longer suitable for use
  • 160-bit hash
  • Invented by NSA
  • Also has severe weaknesses
  • No longer recommended after 2010
  • Invented by NSA
  • Contains many different
    • SHA-256
    • SHA-512
  • 2012 NIST competition
  • Collection of functions
  • Based on Keccak algorithm
  • 224-512 bit hash
  • Has much larger internal state

Birthday Attack

  • Probability that two share a birthday in the same room: 1 – everybody has unique birthday
  • 1 person enters room -> 365/365 likelihood for unique birthday
  • 2 person enters room -> 364/365 likelihood for unique birthday
  • 3 person enters room -> 363/365 likelihood for unique birthday
  • 20 person enters room -> 346/365 likelihood for unique birthday 94.7%
  • Probability that all above happend and all were unique: 365/365 * 364/365 * … -> 58.9% for 20 people
  • 23 people -> greater then 50% probability that two have same birthday
  • MitM does not try to match a specific document that is to be signed
  • MitM tries to have signer sign one of MitM documents
  • MitM tries to find hash collisions

  • Protocols demand that we never sign someone else’s document

  • Always append randomness


  • We sign public keys to proove identity
  • Can be done by individuals in a Web Of Trust
  • Can be done by authorities in a Chain Of Trust


  • Asymmetric crypto
    • RSA
    • Elliptic Curve
  • Symmertic crypto
    • DES
    • AES
  • Hash Functions
    • MD5
    • SHA 1, 2 and 3
  • Combine algorithms to provide confidentiality and authenticity
    • Encrypt message with symmetric key
    • Encrypt symmetric key with public key
    • Compute digest with hash
    • Encrypt digest with private key


  • Java Cryptography Extensions (JCE)
  • KeyGenerator generates SecretKey
  • KeyPairGenerator generates Private/Public Key pair
  • SecureRandom is a PRNG and IvParameterSpec for IV’s in block ciphers
  • Cipher and Signature classes perform crypto operations
  • CipherInputStream and CipherOutputStream hooks into the Java stream model
  • JCE uses maximum AES key size 128 bits
  • Unlimited JCEPolicy extra policy files that allow 256 bits
  • Bouncy Castle can be used as well if default JCE is not enough

Symmetric Java API’s

Asymmetric Java API’s


  • Defined by X.509 standard
  • Contains a subject, validity, public key and signature from CA
  • Subject is a Distinguished Name; hierarchy of information
    • Country (C)
    • State (ST)
    • Locality (L)
    • Organization (O)
    • Organizational Unit (OU)
    • Common Name (CN) (i.e. domain name on a site)
  • Uses Chain Of Trust
    • Certificate signed by intermediate CA
    • Intermediate CA signed by Root CA
    • Root CA pre-installed in browser and is self-signed
  • Used in different Public Key Cryptography Standards (PKCS)


  • Cryptographic Message Syntax
  • Certificates

PKCS #10

  • Certification Requeste

PKCS #12

  • Personal Information Exchange Syntax
  • Private keys

Common File Formats



  • Certificate uses a Subject (Distinguished Name)
  • Certificate has a validity and public key
  • Certificate is signed by issuer
  • OpenSSL has multiple commands for working with different types of PKCS formats
    • genrsa
    • req
    • x509
    • pkcs12

Authentication and Authorization

  • Passwords are problemtic

    • Reused
    • Dictionary words
    • Not enough entropy
    • Phishing
  • Offline password attacks on leaked databases

    • Dictionary attacks
    • Rainbow tables
    • Same hash on different users
  • Using salted hashes makes it harder to attack

  • Password Based Key Derivation Functions (PBKDF) can be used

Computing Password Entropy

  • H = L * log2 * N
  • Common substitutions (0=o, 1=l, 1=i, etc)
    • Log2 of (size of sustitution dictionary * number of characters)
  • Dictionary words
    • Log2 of (size of dictionary * number of words)
  • Capitalization
    • Mostly caps or mostly lower?
    • 1 bit for each different capital not at the beginning of the word
  • Remaining characters
    • Log2 of (size of alphabet * number of characters)

PBKDF (Password Based Key Derivation Functions)

  • Intended for deriving a symmetric key and IV from a password
    • Used in openssl when encrypting RSA key with AES-256
    • Can be used to generate a salted hash
  • Slow down an offline attack
  • Uses Key Stretching


  1. Divide password into blocks
  2. Hash each block
  3. Hash the output of 2 again and xor with previous hash
  4. Repeat n times for each block (n > 10000 preferred)
  5. Append results

  • Might want to use different algorithms so we store the algorithm in the DB
  • Also good for future migration


  • Remove responsibility of identity from applications
  • Separate authentication from authorization
  • Based on trust between multiple parties
  • Identity proved once and authorization granted through different “tickets”


  • Identity Provider (IP) performs Authentication in centralized identity management
  • Secure Token Service (STS) performs Authorization in single repository of roles and responsibilities
  • Relying Party (RP) consumes STS token and takes action based on token claims and can focus on business logic
  • Both IP and STS are providing services so they are usually called IP-STS and RP-STS


  • Both authentication and authorization
  • Used in many OSs including Windows, OS X and some Linux distros
  • User receieves a Ticket Granting Ticket from Identity Provider (IP)
  1. User asks IP for token
  2. IP sends token (TGT) encrypted with symmetric key generated from users password (PBKDF)
  3. User can decrypt the TGT if he knows the password
  4. TGT used to request access from other services that perform authorization

WS-Trust and WS-Federation

  • Protocols for Web Services
  • Defines a protocol and XML schemas for SOAP web services to exchange security tokens
  • Active federation – client machine provides proof of identity
    • Client produces a Proof Key (often asymmetric)
    • Client signs a message to prove ownership of the key pair
  • Passive federation – browser redirects exchange tokens through cookies
    • Password based authentication
    • Bearer token signed by STS and encrypted for a specific RP
Secure Assertion Markup Language (SAML)
  • XML-based
  • Provides authentication and authorization claims (assertions)
  • Assertions signed by STS
  • Enveloped signature with reference to its assertion, usually by ID
  • STS signs the Assertion and Signature

XML Signature Wrapping Attack
  • Signature not always enveloped in the assertion, can appear anywhere
  • Certain SAML implementations vulnerable to exchange of elements
  • Signature has signed the “valid” token and the assertion has been added to another part of the document
  • Implementations might validate one assertion and then use another


  • Used in social applications and mash-ups
  • Delegates access to services
  • Only provides authorization
  • Allows Agents (clients) to perform actions on behalf of User (like 3rd party Web Service)
  • The Agent (Client) is authorized, not the User
  • Relies on signed token request and share symmetric client secret
  1. Client registers with OAuth Service Provider and receives a Client Key and Client Secret
  2. User wants Client to act on his behalf so Client requests a Request Token from Service Provider
  3. Client signs the request with the Client Secret
    • Secret is XORd with one constant and then prepended to the message
    • Result is hashed and key is XORd with a different constant and prepended to result
    • Result is hashed again so that the resulting hash is based on message and client secret
  4. Service Provider performs the same operation using the stored Client Key and generates a One Time Token
  5. One Time Token is sent to the Client
  6. Client redirects the User to the Service Provider passing along the One Time Token
  7. User grants Client access (authorization) to the Service Provider
  8. Service Provider redirects User to Client with a Bearer Token
  9. Client can use Bearer Token to get information from Service Provider on User behalf
Mobile and Desktop Apps
  • No backend, uses API calls from Client
  • Client secret embedded in mobile app
  • Apps can be decompiled to find secrets
  • Very problematic since a User may loose control of the access granted to an Agent

OpenID Connect

  • Originally user owned the identity provider
  • Now it is available through Facebook, Twitter, Google etc
  • Built on top of OAuth although OpenID is about Authentication rather then Authorization
  • Usually Authorization comes after authentication
  • OAuth is not authorizing User however, only authorizing an Agent to act on the User behalf
  1. User wants to access an Agent
  2. User is bounced to Service Provider
  3. User authenticates and creates an Access Token for the Agent
  4. Agent checks with Service Provider if user is authenticated


  • Passwords is most commong and should be hashed, salted and re-hash (bcrypt, scrypt ftw)
  • Tokes are signed to prove vercity of claims and assure trust relationships
  • Weak crypto is sometimes used with Bearer Tokens and unprotected Client Secrets
  • Crypto is great but must be used correctly!

Case studies

  • Some examples of incorrect usage of crypto


  • Social network
  • Reviewed by Gibson Research
  • Reverse Engineered API and published API
  • Snapchat did not act on notification
  • Bad use of crypto

Snap encryption

  • Used AES ECB (weak)
  • Changed to CBC later
  • Still used same symmetric key
  • Key available in Android and IOS apps
  • Find Friends API allowed user lookup by phone number with no rate limiting
  • Symmetric key should have been unique for each user
  • Users should also have unique Public Keypair to exchange symmetric key
  • Snaps should have been signed by the user who took it so receiver could reject invalid snaps (prevent DoS and spam)


  • Reviewed by Adam Langley
  • Goto fail allowed any signed certificate to be used although invalid
  • OpenSSL requires private key for signature so it could not be used to generate a key
  • Trivial to create one anyway using code
  • Should have had better code review


  • OpenSSL library mistake
  • Heartbeat supposed to send back whatever the client sent the server
  • Pointer p with a TLS Heartbeat record could be used to overflow since the client provided the length of the buffer
  • Client could claim to send 64k of data although specifying much less like a few bytes
  • Server would send back 64k of memory that happen to sit next to the bytes from the client
  • Leaves no trace
  • Keys, certificates and other sensitive data could leak
  • Should have had better code review


  • Reviewed by Brian Krebs
  • Attackers installed malware on Point of Sales systems
  • Pin pad gathered pin and credit card data and sent it to PoS
  • PoS intercepted the data and dumped it to a share
  • Attackers remote connected to get the file every now and then
  • Not a crypto attack, needed access to PoS
  • Track Data is unencrypted, chip with encrypted data would have helped
  • PIN number sent to chip causes a unique CVV (iCVV) is created that is used to process payment
  • PIN would then never have been sent to PoS
  • Some Chip and Pin systems have static iCVV numbers though, which opens up for replay attack
  • Dynamic Chip and Pin is much better but Pin Pad could also intercept the data if Pin Pad is infected
  • Pin Pad could then be MitM and steal pin or present different amount for transaction
  • Smartphone could be used to get rid of middle hand hardware


  • Knew about differential crypto analysis without telling the world
  • Dual Elliptic Curve PRNG has constants P, Q and Phi are defined in the specification being suspicious of a back door
    • If exponent e is known such thta Q^e=P it is possible to determine the internal state of the machine
    • Would make it possible to predict new keys
    • Could be that there is no issue, but understanding the full system is important
  • Peer review is critical
  • Simplicity is critical
  • Don’t trust math provided by 3rd party

Lessons learned

  • Avoid static symmetric keys
  • Keep private keys private
  • Use asymmetric crypto to establish trust
  • Dont write crypto code on your own
  • Audit all crypto code
  • Question crypto provided by 3rd party
    • Understand the source
    • Understand the implementation

Jersey Async REST



  • Jersey 1 uses com.sun.jersey
  • Jersey 2 uses org.glassfish.jersey.*
  • Make sure you know which version you are using


  • Jersey does not require servlet framework
  • Grizzly HTTP container can be used
  • Grizzly is a framework using Java NIO API
  • Divided into Core Framework and HTTP Services

HTTP vs. Servlet Containers

  • Servlet Container uses War file with web.xml file and source
  • HTTP Container uses a Main classto launch rest of source and deploys in Jar
  • Lots of other containers can be used (jetty, jdk, simple http, tomcat)

Generating starter project

  • Use Maven archetype

  • Generates Plain Old Resource (

  • Generates with resource config elements


  • Scans for components using packages() and files()
  • Register custom JAX-RS componenets with register()
  • Get and set application properties

Simple example

Testing with JerseyTest

  • Leverages existing jersey components
  • JerseyTest provide both Container and Client
  • Tests use the client to invoke API’s deployed in container
  • Important methods:
    • configure()
    • configureClient()
    • target()
    • enable()

Configuring Container and Client

Invoking an endpoint

Example tests

Test properties

  • It is possible to configure features and properties when running tests

Dependency injection and POST support

  • Using the @Context annotation
  • Many different Classes available for injection

  • Using HK2 to add to @Context and inject our own objects

  • Requires a Binder registered with ResourceConfig

Async requests

  • @ManagedAsync and @Suspended are commonly used annotations

  • Grizzly Threads receives request -> Passes on to Jersey Async Threads

  • Databases (or other Applications) may provide their own async interfaces

  • Application Threads can be combined with Jersey Async Threads

  • AsyncResponse can be used in many different ways

  • Guava can be used in DAO to give it an asynchronous interface

  • URI invoked -> Resource method -> DAO method | ListenableFuture.onSuccess(stuff) <-|

  • Collections and Concurrent hashmaps may cause issues using the built-in Moxy JSON support

  • Good thing we can use Jackson instead!


  • Jackson can process data (json, xml etc.)
  • Register in resource config
  • Watch out for format changes on dates, enums, properties etc.
  • Has many annotations and configs for changing behaviour and formats

  • Jackson can store arbitrary elements that are submitted using annotations

  • Adding XML support

  • Prioritize json over xml

  • Other XML annotations


  • Converts Java type to Stream
  • Can be used to format json and xml differently
  • Uses isWrtieable to determine which MBW to use

Bean Validation, Exceptions and Conditional GET

  • Beans can be validated with Annotations
  • Hibernate Validator is used in Jersey
  • Setup in pom.xml and can be configured in resource config
  • Possible to write custom ValidationConfig class

  • Validate using @Valid and @NotNull annotations

  • Possible to map Exceptions to Responses

  • Use EntityTags to support “If-None-Match” and conditional GETs

  • Use ResponseBuilder to build() response to client

  • ResponseBuild can set any header (cache, cookie, encoding, links, last modified etc.)

PATCH support

  • Extend Jerseys supported HTTP verbs with PATCH
  • Can be used through a custom annotation
  • Needs a custom client connector like Grizzly’s

  • Can be extended by supporting the If-Match header

  • Uses evaluatePreconditions as conditional GETs

  • The caller supply an entity tag which must match the servers

  • If not, it’s assumed the servers tag has changed

Filters in Jersey

  • Supports JAX-RS filters
  • Can modify requests and responses
  • Pre-Matching Request Filter
    • Applied to incoming request before method is selected
  • Post-Matching Request Filter
    • Applied after Resource method is selected but before execution
  • Response Filter
    • Applied after Resource method
  • Filters need modification to use async functionality, runs in Grizzly Thread by default
  • Can use Name Binding to control usage of filters

Filters vs Interceptors

  • Filters
    • Modify headers, entity and other request/response params
    • Executed regardless of wheter there is an entity to read/write
    • Can abort a request and prevent resource method from executing
  • Interceptor

    • Primarily to manipulate the entity
    • Can change properties to affect choice of Message Body Reader/Writer
    • Only executed if there is an entity to read/write
  • Execution Order

    1. Pre-Match filters
    2. Post-Match filters
    3. Reader Interceptor
    4. Response Filter
    5. Writer Interceptor
  • Jersey Filters

    • Logging
    • JAX-RS to Spring Request attribute bridge
    • CSRF protection

    • HTTP method overrides

    • URI-based content negotiation

Custom filters

  • Possible to write custom request/response filters
  • Can use annotations to decide which type of request filter
  • Implements a filter method

  • Use name binding to choose when filter is applied

    1. Define a name binding annotation

    2. Associate annotation with filter or interceptor

    3. Use annotation to flag a resource method (or application)

Java Servlets and Faces Fundamentals

JavaEE Servlets and Faces


  • Java Applet designed to run on a server
  • Extend capabilities of server
  • Java counter part to PHP,
  • Request/Response model
  • Implements Java Servlet API (javax.servlet)


  • GenericServlet
  • HttpServlet


  • 3 phases
    1. Initialize: init()
    2. Send request to servlet: service()
    3. Remove: destroy()


  • Defines user interface
  • Has pre-built tags


  1. Create web page
  2. Associate page with components via tags
  3. Associate components with server side data through managed beans
  4. Create web deployment descriptor


  • 2 main phases

    1. Execute: Translates user input and executes code on the input
      • Build or refresh application view
      • Apply parameters of request
      • Recalculate components
      • Run the code
    2. Render: Translate machine output and renders it to human readable form
      • Generate new UI
  • 6 phases

    1. Restore view
      • When a request for a JSF page is made
      • Builds view and sets up event handlers
      • Put view in faces context index
      • If initial request, go straight to 6.
    2. Apply request values
      • Called on postback
      • Components extract values from request
      • Events that are queued can be broadcast and executed by listeners
    3. Process validations
      • Validates values for components
    4. Update model values
      • Stores local component values to server side components
    5. Invoke application
      • Application level events like submit form and navigate to other page
      • Can go to Complete face or Render response depending on target
    6. Render response
    7. Complete

Managed bean

  • Java object that represents a resource in the JVM
  • Bound to a:
    • Component value to validate some data
    • Component instance to handle events for that component (like page navigation)
    • Converter instance
    • Listener instance
    • Validator instance

Component rendering

  • javax.faces.component.UIComponent
    • Command
    • Form
    • Output
    • SelectOne
  • Behavioral interface
    • ActionSource2
    • StateHolder
    • ValueHolder

Web context

  • Normally one context per application
  • Can also be distributed (1 context per vm)
  • Basic parts
    • Init parameters
      • Specific values to be passed to certains components when application is run
        • Font type
        • Encoding
        • Data
      • Stored in web.xml
    • Associated resources and object value attributes
      • Stored in web context
      • Data and attributes available to all servlets
      • Basically a global storage
    • Functions dealing with logging data
      • Log error messages
      • Store and analyze user traffic data
      • Monitor latency

Client state

  • Requests are not independent
  • Need client state in application (session)


  • Represented by HttpSession object
  • Can store object-value attributes
  • Can listen to binding and activation events for the HttpSession
  • Session uses timeout for expiry
  • Calling a service method resets the TTL counter for the session

JavaEE Fundamentals

Java EE

Difference to SE

  • EE extends SE
  • EE tiers include web, client, business and information tiers with separate tools


  • Web Components
    • JSP/Servlets/EL/JSF/JavaBeans
  • Web Services
    • JAX-WS, JAX-RS
  • Data Access
    • JDBC, JPA (persistance api), JTA (transaction api)
  • Persistent Entities and Java Beans

HTTP Servlet

  • Allows client to interact with server
  • Similar to applet but run by server
  • Generally tightly focused in purpose
  • All servlets have the same methods available
    • init()
    • service()
  • Base class is GenericServlet extended by HttpServlet
  • Can execute Java code and generate HTML

JSP Overview

What is it?

  • A web page
  • A servlet
  • A view
  • Allows for more then just HTML


  • Include: can include files for use in the page
  • Page: gives ability to control things on page, import, sessions, ignores
  • Tag: allows for the use of tags to control libraries of code


  • Use <% %> to wrap code blocks
  • Allows Java execution in JSP file
  • May need additional imports
  • May require use of declarations


  • Use <%! %> to wrap declarations
  • Instantiate objects/variables/methods for use in scriptlets


  • Use <%= %> to wrap an expression
  • Renders object info to screen
    • Fill in forms
    • Render dynamic content

Expression language

  • Expressions to get managed information
  • Communicate well with objects
  • Chaining to get to properties
  • Use ${} to interact with EL

Tag libraries

  • Can be included for use in the page, pre-defined or custom
  • Accessed via the prefix assigned and valid methods from the library
    <%@ taglibname prefix="variable" uri="..." %>

JSP Actions

  • Standard
    • jsp:include
    • jsp:forward
    • jsp:useBean
    • jsp:getProperty
    • jsp:setProperty
  • Other
    • Core library actions on included in standard actions

Implicit objects


  • JSP allows for programming on the View
  • Interaction with the Controller
  • Other ways to navigate
  • Render dynamic content
  • Lots of tools already in place

Actions, JavaBeans and Expression Langage (EL)

Standard Actions

  • Available on JSP pages
  • Syntax is tag/markup language format
  • Most common
    • include – imports resources
    • forward – forwards the request
    • useBean – work with objects get/create
    • setProperty – set the bean object properties
    • getProperty – get the bean object properties
  • Other
    • element – xml
    • attribtue – xml
    • body – xml
    • text – template text for JSP page
    • plugin – embedded objects

Java Beans

  • Serializable class, used as Model
  • Contains a default no argument constructor
  • All properties use get/set/is methods
  • Other properties named in camelCase
  • Not the same thing as an Enterprise Java Bean
    • EJB is more persistance focused on services

Expression Language

  • Expressions give direct access to objects/beans
  • Access to every scope through implicit objects
    • sessionScope
    • pageContext
    • applicationScope
    • header
    • initParam
    • param
    • requestScope
    • cookie
  • Simple and powerful
  • Expressions are wrapped with ${}


  • Actions provide tag-like syntax for common operations
  • Beans is the specification we use to build models
  • EL is used to access the Bean data

Tag Libraries

  • Not included by default
  • Included as directive on JSP page
  • Core tags used for program/flow control on the page without having to use Java
  • Tags reference with prefix “c”

Custom tags

  • Declared with:

    • mlns, xmlns, xsi:schemalocation, version


    • The namespace/package
    • Must match or wont work
    • Link/location is irreleveant
    • Can be a simple identifier [i.e myTags]


Body content

  • Tag-dependent: Embedded commands handled by tag library
  • Empty: No body
  • Scriptless: String literals, EL expressions or tags only. No scriptlets.



  • Create class that extends SimpleTagSupport (tag-class)
  • Implement the doTag() method for execution
  • Must have public mutators for any attributes on the tag

EL Functions

  • Define in TLD file
  • Map to Java class that performs the function
  • Must also define which method to run with its return type and parameter


  • Passed in chains
  • Can be used to parse request and response data for specified paths
  • Filter can for example validate a user before the filter chain can complete
  • If auth filter fails, the filter can redirect to login rather then continue the chain
  • Some older filters have to be defined in web.xml


  • Can intercept data and inspect parameters for validation or authentication
  • Can also modify parameters (uppercase, lowercase, validate)
  • Uses a filter on the request
  • Applied in a filter as the request/response goes through the chain

HTTP Server authentication and authorization (Tomcat)


  • Copy config file for backup
  • Remove all comments
  • Add roles

  • Add users


  • Copy config file for backup
  • Remove all comments (except realm info and ssl port)
  • Comment out
  • Add Realm for memory


Security constraint




  • Configure webserver with keystore
  • Configure web.xml

Spring JPA Hibernate Fundamentals


  • Interface for a specific ORM implementation
  • Actually just a specification thought of as an Object Relational Mapping tool
  • CRUD for Java objects and a relational database
  • Uses JPQL (Java Persistence Query Language)
  • Heavy focus on POJO and its mapping to the database
  • Many providers: EclipseLink (TopLink), DataNucleus, ObjectDB, OpenJPA, Versant, Hibernate
  • Using JPA to talk to ORM makes transitioning easy


  • Controller <-> Service <-> Repository <-> DB
  • Controllers handle requests
  • Service handles business logic
  • Repository saves data to db through EntityManager


  • ORM (sql)
  • OGM (nosql)
  • Search
  • Validation

Configuring JPA

  • Add ContextLoaderListener to web.xml to load jpaContext.xml


  • Add namespaces beancs, xsi, tx, context
  • Add context annotation config and scanner that points to package with classes
  • Add persistance annotation bean post processor to inject persistence context into entity manager factory
  • Create local entity manager factory
    • persistence unit
    • data source
    • vendor adapter
    • turn on to show sql
    • map to jpa property map to set dialect and sql formatting
  • Create transaction manager and enable tx annotations for the transaction manager
  • Create datasource with user, password, url and driver class name

jpaPropertyMap properties
  • hibernate.dialect (MySQLInnoDB)
  • hibernate.format_sql (formats output)
  • (creates database for us automatically)
    • create
    • create-drop
    • update
    • validate
    • none

Entity and Business Objects

  • Is a POJO with @Entity annotation and @Id

  • Good for storing data and maps to the database

  • Business objects can join several entities and be presented to user

Java Persistence Query Language (JPQL)

  • This is not SQL
  • Centered around objects, take care of naming!

JPA Annotations

  • xml and hbm files can also be used to bind objects
  • use @PersistenceContext to get the entityManagerFactory and inject it into code

Fetch types

  • Lazy queries when property is called

    • Can throw LaxyInitializationExeption which is very common when session is clsed
    • OpenEntityManagerInViewFilter can be used to prevent sesion being closed to early

  • Eager queries when object is created


  • Selects the fields we are actually interested in
  • Great way to present objects to UI
  • Objects are added using JPQL-syntax
  • Projection objects can be Jpa Entities
  • Need a constructor for the projection
  • Can join entities into a non-entity (requires getters and setters)


  • Cleaner than adhoc JPQL
  • Not required but focuses on the domain and is stored in domain objects
  • Has named parameters

Spring Data JPA

  • In JPA Persist and Merge (Create and Update) are different methods that return different objects
  • Framework to eliminate boiler plate code in the DAO layer

  • Spring JPA wraps JPA by replacing the Repository Tier to eliminate boiler plate code

  • Can be extended for more complex functionality
  • No support for named queries



  • Uses Spring Data JPA jar (contains incompatable jar with Spring AOP)
  • Spring JPA uses the interfaces to perform the functionality so we don’t need implementation classes
  • Interfaces extend JpaRepository<T, T(id)> and uses @Repository