Pitfalls when Integrating Spring Sessions with Spring Security

Spring Sessions allows you to persist user sessions into a database. Combined with Spring Security, it is easy to create a setup where each logged in user is represented by a row in a SPRING_SESSION table. Externalising sessions into a database is also a prerequisite for a zero-downtime deployment strategy where users can stay logged in while a new application version is deployed.

On paper, the integration of those two Spring components is very easy. Assuming you have a working Spring Security setup, just add this dependency:

<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-jdbc</artifactId>
</dependency>

and add this line to your application.properties:

spring.session.store-type=jdbc

and you should be good to go!

Value too long for column PRINCIPAL_NAME

In my case, the setup was unfortunately not working out of the box. After login, I noticed the following exception:

org.h2.jdbc.JdbcSQLDataException: Value too long for column """PRINCIPAL_NAME"" VARCHAR(100)": "STRINGDECODE('Customer{id=123, email=''email@example.org'', firstName=''Jane'', lastName=''Doe'', company='... (179)"; SQL statement:
UPDATE SPRING_SESSION SET SESSION_ID = ?, LAST_ACCESS_TIME = ?, MAX_INACTIVE_INTERVAL = ?, EXPIRY_TIME = ?, PRINCIPAL_NAME = ? WHERE PRIMARY_ID = ? [22001-199]

As stated in the exception, the data format of one of the newly created database tables did not expect a PRINCIPAL_NAME to exceed 100 characters. The principal in Spring Security is your user object (e.g., a class named “User” or something similar that is used in the login process). Therefore, this error means that there is some problem when Spring Security tries to create the user session in the database.

Continue reading

iPhone Hacks – Should Apple Have Seen It Coming?

In another article I summarized the series of events that lead to a potentially huge number of iOS devices being overtaken by malicious actors. While increasingly more information about these incidents is revealed, one particularly interesting question should be raised: To what extent is Apple to blame?

Fast Reaction

Let’s start with the good news. As Project Zero researcher Ian Beer writes, they have informed Apple about two of the exploits on February 1st, 2019. Apple reacted within six days and released an emergency update (iOS 12.4.1) on February 7th. This short reaction time is exemplary (especially compared to Microsoft – it recently took them more than 90 days to fix a critical Windows vulnerability reported by Project Zero, which resulted in Google disclosing the vulnerability as previously announced).

Sloppy Quality Assurance?

However, this is where Apple’s exemplary behavior ends. Again according to Ian Beer, Project Zero has identified severe mistakes made by Apple that allowed the attackers to circumvent their security. Since Apple declined to comment on the current issue of exploits, his and his colleagues’ views are taken as the only reliable source of knowledge here.

Continue reading

11 Answers to the Latest Apple iOS Exploits

11 Answers to the Latest Apple iOS Exploits

On August 29th 2019, the British security researcher Ian Beer (@i41nbeer) from Project Zero at Google published multiple blog posts about a series of iOS exploits. According to their findings, those exploits have been used to completely take over iOS devices. This article provides focused answers to eleven questions about this series of events.

What is the overall impact of this attack?

If

  • you used an iOS device (iPhone, iPad, …) in the last two years and
  • visited a certain hacked site (more on that later)

your device could have potentially been overtaken by the attacker.

Overtaken means?

Complete access to all your data, including

  • All messages (even encrypted ones, even from WhatsApp and iMessage – of course also unencrypted texts)
  • Contacts
  • Passwords (iOS Keychain)
  • Emails
  • Third-Party Application Data (Facebook, Telegram, Skype, …)
  • Locations (via GPS)

What was the attackers’ goal?

Continue reading

Install Kismet on Ubuntu 19.04 from Source

Install Kismet on Ubuntu 19.04 from Source

Imagine someone watching all your daily activities from hundreds of meters in the distance. While walls can protect you from spy glasses and interested neighbours looking out of their windows, they are no obstacle for electromagnetic radiation. WiFi networks in particular often build the backbone of our homes’ communication infrastructure: when you come home, your phone connects to your WiFi; when you turn on your video gaming console, it connects to your WiFi; when you leave, the WiFi connection to your phone is removed.

There are ways to measure such WiFi activities which require nothing but some cheap pieces of hardware, the right software tools and a little bit of network knowledge. In this post series, I want to investigate this topic, present state of the art tools and ways to set them up and give advice on what can be done to protect against the described invasions of your privacy.

Part 1 explains how to install Kismet – the swiss army knife for network monitoring.

Continue reading

5 Answers About PHP Phar Exploitation

In August 2018, Sam Thomas discovered a new way to attack PHP applications. This exploitation works by causing the application to unserialize a data structure controlled by the attacker and leads to the execution of arbitrary code on the attacked system.

Specifically, this attacks utilizes the phar:// stream wrapper which allows access to Phar application archives. The underlying problem is that PHP unserializes a Phar archive once it is first accessed by a file operation (e.g., file_exists()).

In this post, I answer five common questions about this new vulnerability and what it means for your application.

Continue reading