0

Since I write an API for a website, I'm interested in his login system and his requests but something bothered me, I have the impression that the security system is weak...

  1. When I login, I send POST request containing the login form, but my login cookie is plain text saved ( maybe insecurly deserialized ) -> a:2:{i:0;s:8:"username";i:1;s:8:"password";}

  2. After successful login, the website starts the session: it defines some variable/functions, it's the first thing it does for any user loading. One of these variables is a random 40 string characters, used to validate user requests during the session. This string changes each time the session is loaded.

  3. This website uses AJAX to format POST request. They are sent unencrypted, it's possible to intercept, edit, then send requests without problems. Typical POST request looks like:

POST https://www.website.fr/dataprocess/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 0
Host: www.website.fr

logic=[COMMAND]&you=[USERNAME]&key=[SESSION KEY]

I edited the request to remove every useless elements, in fact this POST can be accepted by the server if I fill bracket with the right data.

Real request body to illustrate what kind of data I send (copy/pasted from wireshark) :

logic=check%3Amail&d%5Bdata%5D=validate&you=apitestaccount&milisec=245&ssrsk=89568&k=788br638757779779168d68a162186678952852z&ismobile=0

I decided to play around by editing request to see what was going to happen:

1 - Legit request with "key" string modified

Result: JavaScript pop-up saying I'm connected from somewhere else 

2 - Legit request with fake username for "you" variable

Result: Empty Response 

3 - Legit request with real username but not mine

Result: JavaScript pop-up saying I'm connected from somewhere else BUT IN ANOTHER LANGUAGE 

I assume that this user has a different language than mine configured on his account...

According bug logs

The request body is interpreted by PHP (array function) - Unknown version

Question:

Is there a risk that a maliciously crafted request, in any way, can bypass the key argument and control accounts arbitrarily? Especially knowing that PHP array() (and maybe serialize()) function are used...

3
  • Without even looking hard, saving the username and password client-side on a cookie is enough to say it's not following best practices.
    – ThoriumBR
    Sep 28 '21 at 20:34
  • 1
    You claim that the site's AJAX requests are posted without encryption, and you support that claim with an example of a post to an https endpoint. That isn't consistent. What am I missing?
    – John Wu
    Sep 28 '21 at 20:59
  • When you write login cookie, do you mean POST Data? Or an actual Cookie?
    – vidarlo
    Sep 29 '21 at 16:02
1

Deserialization of Untrusted Data

You should never ever deserialize untrusted data. This can lead to PHP Object Injection. There is also no reason to transmit data as a serialized object, especially if it's only two strings. HTTP already has an easy way to transmit two strings.

Username in Form

You supply both a user session and a username. This is redundant information and can lead to user impersonation. Generally, the session should already be associated to the user it belongs. There should be a table somewhere in an in-memory database like:

UserId Session ExpiresAt
71257 5ad9aff42efa15cd307f3b467e4a8de4 1632926752
88141 15cff5a3776d357ac508e6631f9787a8 1632934962
71004 2caee914979fe4e3a8a36c2ae48632f7 1632911671
... ... ...

If the username is stored both with the session and given as a request parameter, then one of these is ignored. If it's the one in the request parameter, then you're safe. If it's the one in the session, then you can easily forge requests coming from anyone and impersonate any user, as long as you know their username or user id. Given what you said in your question, I assume the latter is the case.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy