Security with Angularjs and Rest

Asked

Viewed 1,577 times

6

I’m starting with Angularjs and Rest (Java JAX-RS) and I’m having a doubt.

The functions responsible for Rest requests are easily viewed via the browser by right-clicking Exibir código fonte da página.

Therefore, anyone who owns it will be able to access all the information available by the service, even if the Rest server requires authentication, since the user will be aware of all the data...

$http({
    method: 'POST',
    url: "http://meudominio.com:8080/Integracao/rest/produtos",
    headers: {'Content-Type': 'application/x-www-form-urlencoded'},
    transformRequest: function(obj) {
        var str = [];
        for(var p in obj)
        str.push(encodeURIComponent(p) + "=" + encodeURIComponent(obj[p]));
        return str.join("&");
    },
    data: {
        login: "login",
        senha: "senha"
    }
}).success(function (response) {
    console.log("rest: "+response.response);
});

In the above example, a user would have access to URL, login and password.

Is there any way to hide it?

2 answers

5


If the user is not authenticated, the server must deny access to the Apis.

If the user is authenticated, he "has the right" to access them when within the same source (protection against XSS), and it is up to the server to check only if the user has permission to access a sub-resource or perform a certain operation (through something like ACL).

Finally, owning or not the URL will not make a difference, because it is up to the server to block access to the resource designated by the URL. Also because, a valid user might well provide the Urls to another not valid.

Or you could generate unique Urls for each user session, which would be cumbersome, complex, and still require validation of user permissions through ACL (or other feature).

Editing

After the question was edited, the doubt became clearer.

There are two facets to the problem:

  1. At the machine level: in the specific case of user and password, they should be sent only in the login, and during the other requests, use a token that identifies the session, removing the need for the user/password reference until the session is closed. This token should be tied with the machine’s IP and the User-Agent from the browser that performed the authentication. If someone has access to the machine, they can view the information in the browser developer tools, or if they are an advanced user, they can dump the browser image in memory, and they can perform data analysis.

  2. At network level: what should be done is to use HTTPS to perform the requests that traffic privileged information (whether in the request or in the response).

In short: username/password must be traffic only on login. After that, you must use a token that identifies the session and only this token must be routed. All requests that traffic sensitive data must use HTTPS (note that the session token is sensitive data).

Opinion: in my opinion, all requests should be made using HTTPS, regardless of whether they traffic sensitive data or not.

  • I edited my question. Note that the data for authentication can be obtained, so anyone can make as many requests as they want.

0

For example, the REST service is in your application. This way the best way would be for your backend to wait only token to validate the permission and not accept user and password.

One way to work with a solid token in the market would be with the Oauth2 coupled with the implicit flow (recommitted flow to work with javascript frontend), but it would be necessary to change the architecture of its application, but in compensation their application and backend would be safer.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.