Tag Archives: security

[2019 oracle code one] advances in java security

Posted on by
Reply

New Security Control Enhancements – Java 9-12

Speaker: Jim Manico @manicode

For more blog posts, see The Oracle Code One table of contents


JEP

  • JEP = JDK Enhancement Proposal
  • Formal process
  • A lot of work

Crypto

  • See https://java.com/en/jre-jdk-cryptoroadmap.html (java.com/cryptoroadmap redirects here)
  • Java 8 had a lot of changes and enhancements
    • Ephermal cipher suite – rotates keys regularly
    • Better random number support
  • Consider third party libraries for crypto. Key management is hard. Want keys stored in vault. Your code should never touch the key.

Java 9 : JEP 290 – Filter Incoming Serialization Data

  • When you shut down Tomcat, it is serializes everything including sessions into files. When start up Tomcat, it deserializes.
  • Don’t deserialize anything untrest.
  • Can inject malware, read any file, run any OS command
  • Research talked about problem in 2011
  • Learned about problem in 2016 with Apache Commons Collections Gadget
  • Better to use JSON/XML
  • JEP-290 – ObjectInputFIlter interface. Validates classes before deserialization. Validates array sizes and deserialization limits
  • jdk.serialFilter – can specify limits
  • Was backported all the way back to Java 6

General notes

  • In 2017, “friday the 13th json attacks”
  • Turn off features not using: ex: XML DTD parsing
  • Patching critical. Ex: Jackson in last 18 months
  • Live attacks start within hours of framework/library security announcements
  • Security knowledge becoming more specialized. 20-30 people know spring security really well

Other Java 9

  • JEP 273 – Deterministic Random bit generator – as good as can get in Java
  • JEP-287 – SHA-3
  • etc

TLS Benefits (https)

  • Confidentiality – can’t view data
  • Integrity – can’t change data in transit
  • Authenticity – ensure site think visiting is the right one
  • Use everywhere
  • Internal apps can be easy attack vector if don’t use TLS/HTTPS
  • Symmetric key exchange fast
  • Asymmetric is slow. Used for authentication and key exchange. That way the symmetric key is exchanged asymmetrically.
  • All versions of SSL are dead at this point. TLS 1.0 is also dead.
  • Credit card processor charges higher fees if use old TLS version.
  • TLS 1.2+ encouraged. 1.3 is widespread
  • Test at server at https://www.ssllabs.com

Java 10

  • JEP 319 – open sourced core root certs. Now OpenJDK and Oracle JDK use same certs. Had to sign Oracle’s contributor agreement

Java 11

  • JEP 324 – Curve25519 and Curve448. More efficient and security. Important in Europe because NSA involved in prior versions.
  • JEP 319 – ChaCha20 is a new stream cipher. Poly1305 is one time authenticator. Combined they provide an AEAD algorithm. (authenticated encryption.) Again important outside US because can’t export ciphers to embargoed countries. Some US customers adopt as well.
  • JEP 332 TLS 1.3 – Much faster. Easier to configure. Old ciphers removed. Didn’t add much, but took a lot away. Supported by Chrome 65+, Edge 76+, Safari 12.1+ and Firefox 52+

Java 12

  • No JEPs
  • Many small enhancements like the keytool and SecurityManager

Java 13

  • No JEPs
  • Many small features.
  • Support Microsoft Cryptography Next Generation API

My take

I wish this talk was earlier in the day when my brain was working better. The concepts were good. I think the details were lost on me because Jeanne == morning person. That said, I learned a bunch of stuff and I’m glad I stayed for it! I really liked having the JEPs as reference numbers

[QCon 2019] Beyond entitlements for cloud native

Posted on by
Reply

Chandra Guntur and Hong Liu

For other QCon blog posts, see QCon live blog table of contents

General

  • Responsiblity management – group access control, people moving groups or leaving
  • Common solution – role based access

HOCON

  • Human Optimized Configuration Object Notation
  • Superset of JSON
  • Supports comments
  • Supports multi-line strings
  • Allows includes and subsutitions (from request payload or on server)

Eclipse Collections

  • Need more than built in collections

OPA

  • Open Policy agent
  • open source
  • Uses “rego” – declarative native query languages
  • Use REST
  • openpolicyagent.org
  • Contains agent/executable, config and start up scrippt
  • Has IntelliJ plugin

My impressions

The talk was good and full of information. It was hard for me to pay attention because I had seen the talk last week in practice. So it was fresh on the mind and it was the end of a long day. I was also about to run out of power on my device. So I walked around with the mic for Q&A instead of including Q&A in the blog post.

[2018 oracle code one] JWT’s suck

Posted on by
Reply

JWTs Suck
Speaker: Randall Degges
@rdegges

For more blog posts, see The Oracle Code One table of contents

JWT (JSON Web Token)

  • pronounced “jot”
  • JSON data
  • cryptographically signed
  • Not encrypted most of the time
  • Prove that some JSON data can be trusted
  • Common use case: Website generates JWT after validating credentials. Website then sends JWT to browser and browser stores in localStorage. Then browser sends to website for subsequent requests.
  • There are stateless and stateful JWT. The later maps to a session id. People don’t use stateful JWTs.
  • 2012 – Spec came out
  • 2014 – began gaining adoption/marketing
  • seven of the first 10 hits on jwt are marketing pitches

Cookies

  • JWT stores session id as JSON blob. In cookie, just a string.
  • Session cookies are underappreciated
  • Use HttpOnly flag
  • Use SameSite-strict flag
  • Use secure flag
  • Browser sends cookie header to website

HTML Local Storage

  • JavaScript only accessible
  • Store key value pairs in browser

Myths about JWTs

  • JWTs are easier to use – JWTs require additional tools, libraries and knowledge to function. Developer effort. Vs session cookies which are built into all web frameworks.
  • JWTs are more flexible – Cookies can store one piece of data per cookie or serialize into a cookie. JWT has claims which are certain pieces of data that always included – ex: when token created/expires. Cookie actually expires at expiration times. Tokens don’t disappear automatically
  • JWTs are more secure – Cryptographically signed and can be encrypted. However, actually using the encryption feature is rare. The spec is complicated and libraries vary in support. Also multiple vulnerabilities in past two years.
  • JWTs prevent CSRF – Cookies are susceptible to CSRF because sent to server automatically. Local storage is safe from CSRF because developer needs to write JavaScript to send the data. However, you are now vulnerable to XSS which is worse. CSRF is far easier to fix than XSS because most websites link to Google Analytics, third party jquery, etc. OWASP recommends not storing any sensitive information in local storage.
  • JWTs are better for cross domain authentication – Good when create temporary token that lasts for 10 seconds. It is used between the login service and your app.
  • JWTs are more efficient than cookies – 179 bytes. If just sign the id part, is 64 bytes. Difference even greater when add data.
  • JWTS are easy to revoke – Could change signing key of application, but that also logs out the other users. Alternatively, use the revocation list pattern so can invalidate one. But now you’ve introduced state/database/cache.

Better use cases for JWT

  • Short duration (one minute or less) for one time use
  • ex: downloading a file, reseting a password

My take: I hadn’t heard of JWTs. So I learned a lot! It was fun hearing the audience questions/comments/statements was fun. That said, I need to read up on the topic to see the other point of view.