Calculation of pizzerias: Papa Jones, who does not care about security

Picture to attract attention is taken here.

Pizzeria Papa Jones is open in many countries, the engine of sites is almost everywhere different. However, the engine, which was developed somewhere in Russia, is also used on sites for Poland, Kyrgyzstan and Belarus. We will consider it.

You can see the engine itself on a mobile site for Russia , for example. Why mobile? Because the desktop does not even have a registration form, although this is explained by the fact that registration is automatic when ordering. I decided to check once on how things are with vulnerabilities.

Since picking in applications is the easiest, I took it. To my surprise, I found out that the application is just a strange wrapper for the site, although the server can clearly distinguish who the request came from when requesting it. It turned out to be possible to test with equal success both the application and the mobile version. The only difference is that the platform field - mobSite is transmitted for the mobile site, and the applications report the system and version.
')
I succeeded immediately because I started with password recovery. I propose to look at how this happens.

First you need to get the code itself in SMS. Ask for the link with JSON in the body:

POST https://www.papajohns.ru/api/auth/recovery/requestCode { "username": "+79", "transport": "sms", "lang": "ru", "version": "1.0.34", "platform": "Android" } 

The server responds:

 { "status": true } 

Strange data is not enough. Identifier or session at least, but look further.

In SMS comes a four-digit code (only numbers). We will not send it, because changing the password leads to blocking of points for two weeks, and I had plans for them. Let's try to send random:

 POST https://www.papajohns.ru/api/auth/recovery/updatePassword { "code": "1234", "password": "123456qwe", "transport": "sms", "version": "1.0.34", "platform": "Android" } 

I was very impressed. It turned out that when requesting SMS, a pair of phone number + code is written to the database, and when requesting recovery by code, the server checks for the presence of the code in the database and, if found, sets the received password to the database.

The situation gets worse from the fact that there is no restriction on code search. Experimentally, I found out that over a 10 minute search the script is guaranteed to set a password. And if you request recovery for all 10,000 codes from 0000 to 9999?

On May 12, I communicated all the details directly to the developer of the site (well, at least he introduced himself to them). June 19, I wondered how things were going to close the vulnerability. The script sent about three hundred requests and stood up. Having specified the developer status, I found out that the server is now blocking by IP, if it receives 5 incorrect requests. Today I again checked whether the logic has changed, and I am ready to inform you: it has not changed. The server is now also indifferent: I sent 3000 requests without too much difficulty, so that all 10,000, I suppose, will go away without any problems.

The risk of disclosing all stored addresses only by the presence of a mobile phone number remains significant. Bank cards are deleted when the password is reset. They gave me 1000 points and pizza. The pizza is delicious, but the address I will not store there.