Client-Server: How wrong is this kind of request?

Question

Pseudocode: https://pastebin.com/riecfFu4 `

CLIENT CODE:
function Login()
{
    form f = {username, password};
    WWW request = SendRequest("https:/.../login.php", f);
 
    wait request;
 
    if(request.error != NULL || request.message == "ERROR")
        return "Error";
    else
        {
            if(request.message == "LOGIN_OK")
                GoForwardAndLoadNextThing();
        }
}
 
 
SERVER CODE:
function ProcessLogin(form f)
{
    Query q = SELECT username WHERE user = f.user AND password = f.password;
    
    QueryResult result;
    q.DoQuery(result);
    
    // If there was a match
    if(result != 0)
        die("LOGIN_OK")
    else
        die("ERROR");
}

`

Hello! I'm pretty new to web-dev and did only a super simple client-server program many years ago which works pretty much like the pastebin pseudo-code I've sent.

However I figured out that it looks pretty wrong, what if you can just inject "LOGIN_OK" in the request.message and pass your check without it really being valid? It kinda spoils the safety of the client-server architecture?

The protocol I've used to communicate between the client and the server is HTTP/HTTPS, specifically (and I don't know if it is wrong, so please point me out) the client asks for a page on the server (.php) while providing a form, the server responds by writing on the blank page the result (like "LOGIN_OK") which is then read by the client, and in base of what it reads does different kind of stuff, like failing or going forward.

I'm super super new to this, and the only protocol I know is HTTP, how far off I am from this being ok?

If it can help, I'm trying to make a suuuper simple client app that has login/registration where users can write posts, which are fetched by all clients and displayed on the homepage.

Can you point me out in the right direction? Thanks a lot.

I've came up with that kind of architecture to communicate but found it's pretty weak.

Jonathan Nathanson · Answer 1 · 2022-11-07T11:58:11.197

0

You're absolutely right - client code that is running on the user's local machine (i.e. in the browser) can be manipulated and it would be relatively trivial for someone to circumvent your login using the client code you have supplied. If your client code is rendered on the server, the user wouldn't have access to the code so it would be not / less susceptible to such interference. It really depends on where your client is running.

There are common standardised approaches to authentication and authorisation which are designed to avoid these types of problems in client code running on insecure environments. A common method uses OIDC which adds a layer on top of OAuth2 to verify the identity of a user based on authentication performed by an authorisation server.

The (overly simplified) basic principle is a signed token is passed back to the client, containing information about the user's authenticated session. The client would verify this token against the authorisation service, checking the signature is valid.

Protecting the client app's routes is only one part of securing your web application - and is really just obfuscation, as the principle remains: anyone can modify the client-side code to circumvent your authentication. So, any request to a back-end server for data that will be used in your client client app should also be authenticated on the server-side - this is how you prevent unauthorised access to privileged information. This should be used whenever your client application tries to write a new post, or fetch posts to display on the homepage.

This article provides a good introduction to authentication and authorisation concepts.

edited Nov 07 '22 at 11:58

answered Nov 07 '22 at 11:50

Jonathan Nathanson

113
8

Thank you for your answer! It kinda helped me but I think I'm still far from getting it... So basically a token is a way to make sure the user is still who he was when he logged in, when the user logs in, I create a token server-side and save it on the database, then I pass it to the client which will use it for every other subsequent requests, if the token the client pass is different from the one I have stored in the database, there's a problem. But that has to do with authorization? My original problem I think is about the principles of communicating with a server 1/2 – thePOOOISE Nov 07 '22 at 12:15
Even If I add the token authorization process, I would not change my original authentication code, which is my main concern, hence I'd still have if(request.message == "LOGIN_OK") which can be easily bypassed. I'm not trying to make the ultimate secure code or anything, but this way of talking to the server and respond to its messages feels wrong from the bottom, if I have to check client-side the message the server sent me, how that cannot be manipulated on the client's environment? 2/2 – thePOOOISE Nov 07 '22 at 12:18
The token approach I mentioned would be fundamentally different to how you are currently working, and would take some work to update both your client and server applications. With your current approach, you are opening the front-door to your app in a way that can be abused. But you can limit the impact of this - by making sure the client application _verifies_ the user is authenticated before it makes the next calls to your backend to display the information. So when your client app requests data from the backend, such as a list of posts, the backend should check the login is _valid_. 1/2 – Jonathan Nathanson Nov 07 '22 at 15:57
Your backend can check the login is valid if the server code stored a unique token somewhere (usually in a database), i.e. a session ID. The session ID would then be checked before any data is presented back to the client app. There are some really good explanations of this already on StackOverflow - [here is a link to one that covers everything I think you need](https://stackoverflow.com/questions/10097887/using-sessions-session-variables-in-a-php-login-script) 2/2 – Jonathan Nathanson Nov 07 '22 at 16:02
One thing I'd mention here is you could build your entire application to be server-side, making it a much simpler architecture and bypassing a lot of the complexities of doing client-side login to access server-side resources. I don't know if you need a client-side application (maybe you do) - if you do, you should really take the time to learn the authentication and authorisation concepts in the article I linked in my answer. Auth0 has a free plan and loads of tutorials that can help you get started without writing mountains of code. – Jonathan Nathanson Nov 07 '22 at 16:04

Client-Server: How wrong is this kind of request?

1 Answers1