0

Little Info: I am not a web developer, I am a beginner to php and sql. Trying to learn in my free time.

I was examining a web site on a remote server and i saw something like;

www.myurl.com/login.php?username=xxx&password=xxx

First, I tried to log in my credentials and there was no problem. After that i tried to login with false credentials to see what happens.

And I was able to find the link on console.

Is this the right way for security? I could be gravely mistaken but I mean i think now i know which parameters ($username and $password) they store in php code.

If i am right, can this lead to a sql-injection? If so which methods can be used to prevent this.

UPDATE

I forgot to mention that site is HTTP


Any lead is appreciated. Thanks for your time.

  • Worse than SQL injection, you risk a Man in the Middle attack where anyone able to intercept the HTTP request will see the password in clear. SQL injection here is unrelated and will depend on how the login.php page handles the username and password. The way the data is transmitted is irrelevant for a SQL injection. – Elcan Sep 4 '18 at 7:31
  • Thanks for your comment, I will check how Man in the Middle attack works. – Thalthanas Sep 4 '18 at 7:38
  • There is a big problem. The data is transmitted via GET and not POST so the Username and Password will be stored on the PC as a URL in your browser history. Take a look into the difference of transmitting data. – CD Rohling Sep 4 '18 at 7:49
  • Thanks for the clarification @CDRohling. Seems like using POST on logins safer because it is not cached. – Thalthanas Sep 4 '18 at 7:57
  • @CDRohling I believe asynchronous requests are not stored in the history. Am I wrong? – Your Common Sense Sep 4 '18 at 7:58
1

i think now i know which parameters ($username and $password) they store in php code.

No, you don't, consider:

$asserted_user=$_GET['username'];

And even knowing this, the data is ephemeral. Further, if someone can get to a place where they can read the value of the argument, they can also read the code and potentially do a lot of other things.

Having said that, it does hint at a lot of naivety on the part of the developer of the site.

YourCommonSense has already mentioned that passwords will be exposed in clear text in server and proxy logs. But they will also be exposed in the browser history. This is generally considered a very bad method. And all it takes to fix is a change from GET to POST in the html.

can this lead to a sql-injection?

No.

FlorenceUguet says that the is a risk of MITM. There is nothing in your question which has any bearing on MITM. Whether you use GET or POST has no impact on MITM. You didn't tell us if the site was using HTTP or HTTPS. MITM attacks are prevented by using TLS (HTTPS). If the site is not using HTTPS this would be a major gaff on the part of the provider. Even if the sign up is free and the asset value trivial, a provider has a duty of care to its clientele; and that includes protecting their passwords. A lot of people still reuse the same password for different sites.

  • I forgot to mention that the site is HTTP. I've updated the question anyway. Valuable information on your answer, thanks! – Thalthanas Sep 4 '18 at 9:41
1

There is no direct threat from sending the credentials in the query string. Technically, for the server it doesn't matter whether the form data is sent in the request body or in the query string.

So it means that your initial assumptions are all wrong:

I think now i know which parameters they store in php code.

First, such a knowledge will give you no advantage.
Second, you can see in the browser's console ALL parameters sent to the server, no matter what method is used - the request body parameters are shown in the console as well

can this lead to a sql-injection?

Of course not. SQL injection is related to SQL, not HTTP which you are talking about.

The only threat here is a chance to expose the password to a third party. First and foremost, it will be stored in the server's access log. Or it can be stored on some proxy server along the way (however, in case the site is using HTTPS, it won't happen).

So in the end, you aren't likely going to gain any advantage in this case but it's better to use the POST method anyway.

  • Also worth a mention that putting the password in the GET request can result it in getting stored in your local browser history. This can be more of a threat than anything else, depending on how you are accessing the site (e.g. on a shared computer). – Conor Mancone Sep 4 '18 at 9:28
  • @ConorMancone from the remark made by the OP, "I was able to find the link on console" I make it that in this particular case it was sent asynchronously, but you are right, for the generalized answer it's better to mention such a case too. – Your Common Sense Sep 4 '18 at 9:34

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.