Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Klarna users are being signed in to random accounts

twitter.com

Post reply on HN
Print view View original

301–310 of 517 posts

Re: Klarna users are being signed in to random accounts

#301

Post by chrisrogers »

irjustin wrote: post #269
mavster wrote: post #181

I'm just guessing, but... "developer gets a great idea - let's push an update to the API as a GET request so we can cache this on the CDN... forgetting that the JWT token is potentially returned in the call. Now, whoever makes the call first gets their JWT token stored for everyone else to load instead when the API call is made." Ta-da, Klarna.

I can 100% see this being the cause if this comes out as the root. But... API's really shouldn't be cached? At least not at the CDN level. The risk of serving up stale dashboard data alone makes users go ????... and we definitely don't want - not even mentioning the problem here, that's crazy.

Depends on the scope of the API of course, but it's a good rule of thumb for any API with private auth

Re: Klarna users are being signed in to random accounts

#303

Post by adflux »

the_monocle wrote: post #157
Raed667 wrote: post #110

Totally anecdotal, and probably unrelated, I interviewed for Klarna a few years ago. Mid process, they sent me some sort of timed bizarre IQ test that the recruiter claims EVERYONE who works there has to take. That's when I knew that kind of working culture wasn't for me.

A recruiter contacted me aswell and I asked about their salary. They pay 50k euro for juniors in berlin with afaik no stock vesting. How they even manage to get qualified personnel is beyond me, I would expect much more for a fintech with over 3B evaluation

50k in euro's is pretty ok for European developers, no?

Re: Klarna users are being signed in to random accounts

#304

Post by henvic »

geofft wrote: post #280
henvic wrote: post #253

As a software engineer, I hate when I add a check for something "that will never happen" but that if happens is awful, and people complain. A classic example: you need to get a user from a session, check against a database, and continue if they're signed in. Then I add a simple if databaseUser.Username != form.Username and people will say "if that happens we've something worse wrong". Geez, something might be wrong a…

I think there's merit in objecting to "that will never happen" checks in some cases (though, to be clear, I'm not saying the people objecting to your code are thinking about the same thing I am). Specifically, if you have data that is loaded from some other source, your extra safety check might be checking data that's loaded from the same source, in a way where if something did go wrong, it went wrong in both places…

> I don't think there's a recorded case of that ever happening with databases. > and there are other seams in your code which are much more likely to break.

One such thing is the abuse of layers and layers of abstractions. For example, many people (unfortunately, in my view) love to use ORMs and query builds, and things like these are much more easier to happen when things are too generic.

And signing the entire database row and validating it, and so on, might be unjustified for most people, especially if you already count with correction from a TLS layer, and you can just have the trade-off of adding a simple conditional to check if the data you receive is sane.

This is not something essential for everything, but that is nice to have, especially the further you're out of control.

For example, if you retrieve data from an external API you should not trust it blindly, but rely on your internal references (security concerns aside, I'm talking about other kind of erratic behavior or bad data).

Re: Klarna users are being signed in to random accounts

#305

Post by duxup »

_nnv7 wrote: post #273
duxup wrote: post #268

Earlier quoted context omitted.

I don't understand your perspective here. Debates about Agile have gone on for ages, that's not a 'lately' thing. I have no idea what 'hipster' has to do with banks and tools... or what you mean by 'old proven methods'.

Not looking for a debate myself :)

I was less interested in a debate as to what meaning you assign those terms. The way you use them seems like empty buz words.

Re: Klarna users are being signed in to random accounts

#306

Post by jojohohanon »

henvic wrote: post #253

As a software engineer, I hate when I add a check for something "that will never happen" but that if happens is awful, and people complain. A classic example: you need to get a user from a session, check against a database, and continue if they're signed in. Then I add a simple if databaseUser.Username != form.Username and people will say "if that happens we've something worse wrong". Geez, something might be wrong a…

A lifetime ago I was writing code for airline data processing. The specs are very clear about what the valid representation of every field was (less so about what they meant, but...).

So we generated our parser to fail if field ORG/1457 (made up) was not numeric max 8 digits. Or missing where mandatory.

Even if we never touched the data in that field.

Turns out that no-one else used the spec that way. No two were the same, so we had to basically implement two layers of parsing. One to put the data in a common parse tree, and the other to per-sending-mainframe interpret the data as how the sender had implemented.

We assumed that the mainframe would never send illformed data, and indeed that-could-never-happen. But they differed in what they thought was well formed.

Re: Klarna users are being signed in to random accounts

#307

Post by eli »

nly wrote: post #289
oxplot wrote: post #278

Earlier quoted context omitted.

That only protects the user's password. The auth cookie will be sent in all subsequent requests in plain text. EDIT: that's how firesheep ( https://en.wikipedia.org/wiki/Firesheep ) hijacked sessions for e.g.

That's not true. Cookies can have a 'secure' attribute which tells the browser to send them only over TLS

in 2011?

Re: Klarna users are being signed in to random accounts

#308

Post by jacquesm »

henvic wrote: post #253

As a software engineer, I hate when I add a check for something "that will never happen" but that if happens is awful, and people complain. A classic example: you need to get a user from a session, check against a database, and continue if they're signed in. Then I add a simple if databaseUser.Username != form.Username and people will say "if that happens we've something worse wrong". Geez, something might be wrong a…

This is very good practice as far as I'm concerned. Functions should treat their arguments as potentially hostile input.

Re: Klarna users are being signed in to random accounts

#309

Post by chc »

nly wrote: post #289
oxplot wrote: post #278

Earlier quoted context omitted.

That only protects the user's password. The auth cookie will be sent in all subsequent requests in plain text. EDIT: that's how firesheep ( https://en.wikipedia.org/wiki/Firesheep ) hijacked sessions for e.g.

That's not true. Cookies can have a 'secure' attribute which tells the browser to send them only over TLS

But that just makes your login not work if the rest of your site is HTTP, doesn't it?

Re: Klarna users are being signed in to random accounts

#310

Post by akamia »

mavster wrote: post #181

I'm just guessing, but... "developer gets a great idea - let's push an update to the API as a GET request so we can cache this on the CDN... forgetting that the JWT token is potentially returned in the call. Now, whoever makes the call first gets their JWT token stored for everyone else to load instead when the API call is made." Ta-da, Klarna.

I worked with a team that owned a service that resizes images. An engineer was assigned a task to add support for auto rotating images. His solution involved saving the image to a file and then using a library to handle the rotation. He used a hardcoded value for the file name. In a local environment where requests are sparse this looked fine to him and other engineers on the team missed it in code reviews. It wasn't until it went out to prod that he realized the error in this. Users started seeing other users' images because the file's content was constantly being overwritten.

When you test features like this or caching a response with a JWT it can be very easy to default to the happy path or ignore the impact of a large volume of concurrent users.

Post reply on HN