I'm using web api for my application on ASP.NET CORE
If someone see application soruce code, there is a backend url, isn't it?
Then, that guy can use my api if he succeed my application decompile
How protect that situation
I'm just stutdent, so... Just my curiosity
Authenticate your API
If you plan on having a private API (not open to everyone), then you should force users to authenticate themselves by using an API access token. Each token should be specific to a particular user, and there should be consequences for distributing a private key (such as revoking it and blocking the person associated with it) or else people will just share them without care. This will allow users to communicate with your server and run commands or queries as they please. Assuming you have written these functions correctly, they shouldn't allow an attacker to access much beyond his given scope of given API functions (which should be queries at most).
Document, document, document!
You shouldn't allow users access to your source code for this. You should document your API thoroughly regarding details which methods the user can use, what sort of data it expects to receive, and what sort of data you will get back from it (including all errors, possible problems with the users request, and how to fix their requests). Make sure you heavily test these too, and make sure that you can't perform any sort of malicious actions with your API. It's also a good idea to give your documentation to another person and ask them to read it. If you've missed something important, you will know afterwards because there will be a clear gap in their knowledge of the API.
What, not how
Users should know what a function should do, but not how it does it. For example, I could use /api/GetUserById. I should know that I can get a user - I shouldn't know how it gets the user. The only thing I need to know is that I perform this call and I get back a json object with details about the user. That is it.
As with any of my posts, if there's something I've missed or something you need further clarification on, please let me know in the comments and I'd be happy to explain further. I hope this helps
Related
JHipster implements several best practices for authentication and authorization.
Mainly described here: https://www.jhipster.tech/security/.
But I still do not see an example how to design a solution, which does not involve putting user verification logic all over the place for a very common use case.
Let's say you have a WebPage using REST-API like BankAccountResource from JHipster Sample App and you want to restrict this to only ADMIN role or currently logged in User. Let's say you have 50 of such services for your customers: BankAccount, Address, BillingAddress, UserData, Devices... For every resource a GET and UPDATE must be restricted. Also loading device /api/device/{id} might not include user-id.
How do I prevent UserA from loading UserB's device by guessing it's id?
How do I avoid planting that code in every method?
I guess JHipster/SpringSecurity has concept/objects to handle such use cases. Could you point me, explain how to use them please?
Maybe this question helps a little bit: Restrict URL access control by id in jhipster
Spring Security hast PostFilters to check if an object e.g. loaded by a method may be accessed. If you need more control you can use Access Control Lists for fine grained access control.
References:
https://docs.spring.io/spring-security/site/docs/5.3.0.RELEASE/reference/html5/#domain-acls
https://docs.spring.io/spring-security/site/docs/5.3.0.RELEASE/reference/html5/#method-security-expressions
I'm building a service that provide some readonly information that is going to be used in multiples websites, some with login and some public.
I dont want to make the api public to any website so I'm not sure what auth method i should use. I have some ideas but I don't want to reinvent the wheel.
I was thinking on have the backend of this sites request a token to my server using a secret/password/private_key then they should pass this token to their front end and pass it with each request to my server(their front end will comunicate directly with my API)
If your public non-authenticated API is accessible by your site, there's no way to stop other people from consuming this API and stealing your data.
You can stop other websites from directly taking data from your API (by not using CORS headers), but if your website is showing data from your API publicly, then assume anyone else can.
If your business relies on not being possible, rethink your business model. If data appears on the screen of a random user, it means that user can take that data and put it somewhere else. It's how the web works.
I totally agree with #Evert. Having said that, there are some ways you can use to make public API accessible to some and not to all. It will not be perfect, and using some kind of API tokens will be a better solution most of the time, but it might suit your needs.
First of all you can use firewall rules and allow connections from certain IPs only. Simple and will work as long as the source IPs do not change.
Another idea you can use: look at youtube and how private videos work. There is a secret in the URL. With enough entropy you can build publicly accessible URLs this way which can be used to share a simple link with friends, but will be hard to guess by others. There are drawbacks to this technique. You may only allow people to share their content this way, as they have always the rights to make the link public by pasting it into their tweeter/yt/other.
I want to write a google chrome extension, that should make a request to my website to send and get some data, so, actually I should do an ajax request like it is written here https://developer.chrome.com/extensions/xhr.html
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://api.example.com/data.json", true);
I wanted ask if there is a way to somehow secure the code or prevent others from using my api, because actually the other users can see the source code of the extension when they install it and so use my api without me being aware of it.
EDIT:
If I need to make some sort of authentication, than how can I authenticate the user before making the ajax call ? for authentication I will need to send a request to my server , but for that I should send , e.g. username and password, that should be saved somewhere in the extension's files, which, in fact, can be seen by the users, when they install the extension.
Thanks
Don't trust the browser, take steps to authenticate the user instead. So, in this case, you could require that YOU enter in a password that is used to communicate with your server.
Your Google extension would simple require you to enter in a password before it attempts to use AJAX to communicate with your server.
Be aware that you should build in means of protecting yourself from brute-force attacks. So, do things like lock everything down if there are more than some small number of wrong passwords, etc.
You could also consider using the password to simply decrypt the destination of the XHR, but if you go this route, you should store this very carefully, because this will be brute-forceable offline.
EDIT
Trying to lock down an API so that only a single application can use it is just not practical nor technically possible, so you're only hope of doing this is to authenticate the user using the API, regardless of the accessing software he is using. You could have the user sign an agreement that legally limits them to only your extension, but I suspect this will go largely unenforceable and will consume your time tracking abusers down.
If you don't want unauthorized people even knowing where the API is, you could perform authentication using an out-of-band mechanism: over the telephone, email, SMS, or simply, another API that will grant the user a password or token that requests to your API must be accompanied with.
During this out-of-band process, you could also grant the user, a unique URI (the API access point) that is only valid per authenticated session (https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/, for example). Any requests to your server on OTHER URIs simply won't work. However, this isn't theoretically much different than using the same API access point, and having a good password. It just changes the number of places in your architecture that will be performing authentication and/or authorization checks.
<aside>My vote would be to reduce the number of authorization/authentication points to as few as possible so that you can spend more time on getting that one place correct rather than having multiple places and possibly multiple logic flaws or other things that could lead to vulnerabilities.</aside>
You could also explore using Public Key Infrastructure and/or one-time passwords schemes or device-based token generators, etc., but in the end, you'll be allowing authenticated and authorized users to use your API. And, thanks to the Internet, this will not remain an undisclosed URI for long.
And, more importantly, it will not prevent someone from using the data on their own. Even with all these measures in place, it would be trivial for an authorized user to collect this data as it is being streamed to your extension. Or, if you employ point-to-point encryption, they could screen-scrap or use some form of JS introspection on your very code or even extract the data from their computer's memory.
I know you were looking for a silver bullet here, but it doesn't exist.
I think you are doing it wrong. You should never trust what's going on on internet users PC's. Never!
Move the line of trust one step inward, make your API public and then design the security where you have perfect control - server side.
I could not get correct aspect of your use case
Few Points:
Your extension code is always traceable( Any one who has installed extension can view the code)
If you are looking for security through complicated or obfuscated coding patterns you end up slow down of understanding process not the whole.
If your target is to ensure users who install your extension should be able to access and inert all other users( Who have gained illegal access or downloaded and edited code) have a session shared key per installation.
Please explain further use case so i can help you better.
I was reading through the windows live developers doc here. In that I saw they are having an authentication method something like this.
GET https://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&
response_type=RESPONSE_TYPE&redirect_uri=REDIRECT_URL
I understood everything except for where do I give the username and password of the user?
I am planning to create an app(first one in my life) to learn the working.
I also have never used or coded something over REST.
When using OAuth, your application never receives the user's username or password. Rather, the user logs in to Windows Live on the Windows Live servers and authorizes your application for access to their information. After they have authorized your application, you receive an access token from Windows Live on behalf of the user. You then use that access token with the Live API to retrieve user information.
Coding something using REST protocols isn't anything too terribly complicated. It has been my experience that you're just specifying parameters to the API using GET or POST as your request method. Adding OAuth on to your requests is a matter of specifying additional parameters.
You're task is to learn two things here since you've never done REST or OAUTH before. Spend time looking at both.
Oauth is hard to get and hard to implement.
You should choose an off-the-shelf Oauth library they exists for most languages.
(Then you do not have to worry about the details. OTOH: You should know how it works to know how to set up and fix if something goes wrong.)
http://oauth.net/code/
Creating a API here and I want people to be able to make simple mobile apps that could get the username/password of my users and of they go to interact with my server. So I need to have a Basic Auth(OAuth and other stuff are also going to be supported, mostly for a different use case). Right now I have a example from a Book saying i could just receive the (unencrypted) password as part of the post and looking at successful APIs I see that twitters gets unencrypted passwords on the headers of their HTTP request.
Another options would be to get md5 or SHA1 hashes, but without a secret salt, this seems like an exercise in futility. I asked a couple of people and everyone had a different(strong and heuristic) point of view, so....
What is the best way to get passwords for basic auth in a API and why?
Uh, do not give out the passwords of your users to other apps. Or via your API. Or ever. They should be stored 1-way anyway (i.e. hashed).
But I'm not so sure if that is what you are saying. You talk about OAuth (which you can use to generate tokens that let API's access various components of your system, because the user says that it is possible).
For example, say you wish to allow API-users to query a certain users properties (say, their location), then you create a token for this access via OAuth, and the API-caller passes that. At least, this is my understanding of the model. Obviously, you should review OAuths webside, and find an appropriate implementation for your given language.