tl;dr 🔗

The service uses the industry de facto standard for high security in Norway - BankID - for authentication, but still missed authorization check on a HTTP PUT call. A classical weakness to be found in web apps of today.

Summary 🔗

Background 🔗

Acme is a "service booklet" for your home. It's a place to store all of the documentation about who's done what and your proof that all is ok if you were to sell your home. Everything about my house is stored at their servers.

I got a "snap" of 5 scratch tickets from a friend that he got from Acme for reporting some problem with him getting the wrong house number. I thought maybe there could be an easy way for me to get some scratch tickets as well.

Approach (technical stuff) 🔗

This was a quick one I did while grabbing some lunch one Saturday.

Browser developer tools 🔗

I logged in to Acme using BankID and having Chrome DevTools open. I surfed back and forth and got an impression of the web app and got a list of URLs that was being called + headers and cookies and whatnot.

As with most web apps today there were a lot of Ajax calls going on, transferring JSON. I then tried replacing some IDs in URLs. In general stuff seemed pretty good. The security seemed to be in place.

Then I saw this sort of "task list" where you have these set tasks - and can create new ones - for stuff you need to do with your home. You can also share them with third parties so they can do them for your and sign of on the work done. Once finished can set the task to status Done.

Curl 🔗

Most developer tools for browsers let you copy any HTTP request as a Curl command. I got an ID of one of the tasks of my friend and his approval to change the status of it.

I've changed URLs and IDs, but otherwise it was this command used:

curl 'https://example.com/UpdateTask' \
    -H 'Cookie: <some cookies for BankID, session and Google Analytics>' \
    -H 'Origin: https://example.com' \
    -H 'Accept-Encoding: gzip, deflate, br' \
    -H 'Accept-Language: nb-NO,nb;q=0.8,no;q=0.6,nn;q=0.4,en-US;q=0.2,en;q=0.2' \
    -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36' \
    -H 'Content-Type: application/json;charset=UTF-8' \
    -H 'Accept: application/json, text/plain, */*' \
    -H 'Referer: https://example.com/app/index.html' \
    -H 'X-Requested-With: XMLHttpRequest' \
    -H 'Connection: keep-alive'  \
    --data-binary '{"taskId":<some other person’s task ID>,"status":true}' \
    --compressed

And bingo, the server returned HTTP 200 and the task was changed.

Session management 🔗

Returning to my computer some time after doing this, the browser told me I got logged out because of the session being timed out. I tried one of the Curl commands one more time and saw that the HTTP request went through and returned HTTP 200. Apparently I was still logged in and had a valid session even though my browser told me otherwise.

Classical issue 🔗

I think this is one of the more common issues in web apps today. When authorization of GETting data is in place, one have a tendency not to check if the client is allowed to do what he's telling the server when PUTting data back.

Reception and handling 🔗

Day zero 🔗

I sent an e-mail telling about the two minor issues.

Day 2 - before noon 🔗

I got a long and well-written reply thanking me for finding the issue and telling that the developers were looking at it. They also went on telling that they were growing and there was a new employee coming in who would have the service's security as its responsiblity.

Day 2 - night 🔗

I got an update. They had found the authorization issue and were in the process of fixing it. In regards of the session still being valid they said it was just that the sever had one hour session timeout while the JavaScript app had it set to 20 minutes.

Anonymous you say? 🔗

I contacted Acme telling them that I was posting this. Until then they were very professional and open, but suddenly they became a bit defensive. And they wanted to "inform me" that I had broken their terms the moment I had checked if they had any security holes. They did not want me to mention their company name or brand. They were afraid of the media. I can fully understand that. Who doesn't want to protect their brand?

I think they have handled the situation so well, and the issue was so minor, that I want to encourage them to come forward.

Conclusion 🔗

This was a minor issue, but an issue I see quite a bit. The reception and handling was good, at least until I told I was publishing this. Developers: Go and check those POST and PUT requests and double check that you verify if the client is allowed to do what it wants to.