So assume I'm using some external API, where I'm required to send it an ID and passkey such as http://whatever.com/api?id=asdfg&key=_hjkl&request=whatever
I'm going to need to have that ID/key stored somewhere and I could get away with not exposing it to the user by putting it in a database or something, but whenever the request is actually shot off is there no way to hide it?
No, there isn't.
If you want the client to authenticate against a service, then the client has to have the authentication credentials. Anything you give to the client, you also give to the user of the client.
If you want to add some kind of protection, then proxy it though your own server or use a time limited token - but keep in mind that anybody can still hit the appropriate end points to get access.
If you are giving data to the client, then you are running a public API and it is best to think of it in those terms.
If the api provides a POST method, you can use that, without having to show the parameters.
Using POST method to hide URL parameters
Related
I am doing a Website 100% in ReactJS, It's a simple/medium complex, this has a Login, Profile and other sections more. After Users Log into the site the login callback returns some important values like: "Token, UserRole". Currently I'm storing these values in Web client using localStorage .
My doubt is the next: There is a better way to store this values? Because if any person changes the value from the Browser Console this could be a BIG ISSUE because they could change the role and then execute things that they never should do.
I thought to do it with Redux, but if the users Refresh the website then they lost the values, so I am not pretty sure to choose this.
What do you think guys?
TIA!
The general rule is to never trust any data stored client-side, except for an authentication token or the equivalent. All changes that the user makes that involves the server should be verified on the server. So, rather than:
if any person changes the value from the Browser Console this could be a BIG ISSUE because they could change the role and then execute things that they never should do
Instead, the right thing to do would be, when the client wants to do something (such as edit their profile), have the client send their authentication token (or session ID) with the rest of the payload to your server. Have your server examine the token, check that the user associated with the token actually does have the required permissions for what they want to do, and only then continue to process the request.
Whether you also happen to store some information in Redux or elsewhere has no impact.
Storing login-related information client-side is relatively common and isn't inherently bad - just make sure to always verify it on the server when something that requires permissions is requested.
One approach some use is for the server to create an encrypted JWT that only the server can decode, which gets sent with requests.
Whenever you call api from angularjs,its shows basic details of api on browser console like (endpoints,parameters,response), so is there any way to hide or secure this details? Or how to encrypt my parameters and responses?
so is there any way to hide or secure this details?
endpoints
Nope. The client must be able to use them. If your JS can see them, so can the user.
parameters, response
Nope. Theoretically, you could encrypt them, but this is ultimately a meaningless activity, as the client must possess the keys needed to decrypt everything, and the user will have them too.
I have been thinking over this issue from past few months. Recently, I have started with complete JS Built front-end, where the forms are posted using Ajax.
I have a doubt, how to recognize on the server side, from where the data is coming from. Is it coming from actual form event or it is coming from browser console.?
What I have tried:
Creating a two way handshake: Before posting the form, the Application will contact the server, and the server will send a token inside the cookie, which will be sent back with the form post. But, even if we post by browser console, that cookie will go carrying the token. So, Failed.
Binding Hidden Field: But if someone, is posting the data from browser console, he would definitely look for the hidden fields as well. Basically, he'll replicate my AJAX to send the same request, in the same fashion. FAILED!!
I am not able to figure out this part. Can anyone help?
Thanks in advance.
Rule #1 of programming for the Internet: Never trust anything from the client. EVER.
Rule #2 of programming for the Internet: Never trust anything from the client. EVER.
Rule #3 of programming for the Internet: You can not make the client trustworthy.
I know the first rule is duplicated twice, but it is worth it.
There is simply no way to do what you intend to do.
A person who wishes to send data to your server, via an AJAX request or a POST request, can easily do any of the following:
Modify the form using browser tools or a proxy and force-feed in whatever information he wants.
Capture the entire transaction, through a tool like fiddler2, and change the values and re-send them. No browser needed.
Modify the code running from your site to send (or allow) whatever data he wishes to send.
Use a tool like Curl to fake an browser and send whatever information he wishes to.
There is simply no way of knowing, on your server, where that information came from.
From a security point of view, you simply can not trust anything -- ever.
Validate the credentials, give the user a login token (usually a cookie) and then still be suspicious of everything the client sends you. If there is something that shouldn't be changed or updated, make sure your back-end doesn't allow it to be changed or updated.
We have tons of code in our application that looks like this:
if (user.HasPermission("MayUpdateFirstName") {
record.FirstName = FormData.FirstName
}
That way, if FirstName is passed in, and the user can't modify it, then it doesn't get modified.
I need to understand and maybe ideas about single page apps.
I want to create a project, i'll do it with MVC. I also want to use AngularJS for client side programming.
I know that AngularJS is good for single page applications and when working with SPAs you send your data to API to process. But data sent from Angular is visible to user and open to be manipulated.
I don't want users to be able to see any data or access to the API from the internet. Witch way i should follow?
I'm thinking about keeping sensitive user data in MVC controller. For example let's say user Id is very sensitive for my project. If i keep user id in javascript variable, when i'm sending it to API with some command user will able to change the id and manipulate the system. But if i keep user-id in MVC controller, via user authentication, and send request to my MVC controller then the user won't be able to change it. But i know this is not the best way of doing things, there must be a more clever way.
I'll be glad if someone can explain how this things works in SPAs or when you use Angular and MVC together.
This won't work, you can't prevent user from tampering the data, crafting custom request and doing whatever she wants at her side.
What you should do is to never trust upcoming data - which means validate every incoming id twice, once when you produce it and then when it comes back. Either it comes plain and you verify if it's legal or you encrypt it so when it comes back you decrypt it.
Some data can be stored at the server side, the id you mention is such example. This way user never sees the data, what you pass is the session id which is a long random value, rather impossible to craft. This approach comes with the cost of server side resources that are used, the more users the more resources at the server stored between requests.
In the application I am currently developing we are using ASP.Net forms authentication to grant the user further access to the site. This site is targeted towards mobile users and as such we are attempting to be as hands off from the server as possible and make use of KnockoutJS to make the web service call and load the data so that the user can view it.
Right now the webservice (REST service using GET method) requires the username in order to load the data specific to that user. I have this information on the server side (ASP.net) and I can easily access either User.Identity.Name or access the forms authentication cookie directly and pull the information.
My problem is that I need to get the username from the server to the client so that the service call can be made. I have looked into doing this securely but so far have come up blank. Currently I am passing the username as a url parameter and parsing it out using JavaScript, with a check on the Page_Load method to verify the username in the url matches the logged in user.
I need a way to secure pass a username from ASP.Net that has authenticated the user using form to the client side JavaScript so I can make a REST webservice call.
EDIT: So after googling and meeting with my team lead I think we will be using an OAuth implementation similar to this example:
http://www.c-sharpcorner.com/UploadFile/surya_bg2000/secure-wcf-restful-service-using-oauth/
Also for anything else looking for the same answer I found this question very helpful in understanding OAuth:
What's the point of a timestamp in OAuth if a Nonce can only be used one time?
Assuming everything is implemented correctly would it be more secure (totally secure, secure, or more insecure?) to instead pass the generated signature via an ASP tag as mentioned below?
EDIT 2: After some more review and some more searching we finally decided on a framework and method of making this work. As it turns out OAuth isn't necessarily the answer here, this questions:
But Seriously.... Example of ASP.NET WebAPI implementation including OAuth
was a lot of help as well in figuring out how to make this work. What we are going to end up doing is generating the signature and putting in on the javascript and making the call like that. The signatures are going to be time sensitive and regenerated each time the user loads the page so very OAuth like but we arent implementing the full spec.
TL:DR Final solution was to generate a hash signature and put it on the page via ASP server tag <% aspvar_here %> and use it to validate the service call
Simplest way would be to render this javascript in your page:
<script type="text/javascript">
window.UserID = '<%=HttpUtility.JavaScriptStringEncode(this.User.Identity.Name)%>';
</script>
Now you can reference it in your JS.
But, more importantly, if this user id is not used just as a default parameter but instead to authenticate the user, this is a security hole. Normally the REST service should also be able to look at User.Identity.Name instead of receiving it as a argument.
Normally the username is provided by the client to begin with. It is then verified on the server-side (using whatever authentication is necessary, such as a password).
If it has been verified on the server side (in your case, this must be from a WCF web service as ASMX does not cope well with REST), then you can be sure that it is correct - plus you already have the username on the client-side.
EDIT:
As Knaģis pointed out, you can get it using an ASPX tag, presuming the page is an ASPX page and not HTML.
If you just want to have the username in the client side, the other answers explain how to do this.
But as you stated, this IS a security risk. Someone can modify the data on the client and impersonate another user.
The correct way to do this:
After a user successfully logs in, a Guid is issued which uniquely identifies this user.
The Guid is the token which is saved on the client and passed to the server not the username.
All webservices receive the Guid not the username.
Server has a dictionary which converts the Guid to the original username.
Another option can be to encrypt the username and pass the encrypted value to the webservice. The webservice will need to decrypt the value in order to get the username .