I am working on creating a toolbar application that will invoke a URL on the server and increase a User's points(as an incentive to use the toolbar). Right now the URL is a GET(I can and will change it to POST).
The issue is, I need to make sure that someone cannot, using any sort of a hack, increase the points. The URL is ofcourse a publicly accessible URL.
Will Basic HTTP Authentication make sense in this case? If yes, wont I need to store username-password with the toolbar, which again can be easily hacked?
-thanks
if I'm not mistaking Basic HTTP Authentication send the password in clear text over the network
I suggest you to use Digest HTTP Authentication + TLS/SSL
Related
Let me explain in detail
I've 2 servers hosted and one of them for Back-end and other is for Front-end.
Back-end server : 127.0.0.1:8000 (just for explaining)
Front-end server : 127.1.1.1:9000
User requests UI from Front-end server and if he wants to create an account on my website he needs to send POST request to 127.0.0.1:8000/create-account/ and this works fine
but if I open console of other website or make use of Postman, I'm able to achieve the same results.
So I want to prevent this thing and only allow anyone to create account from my website only.
Methods which I've tried
I've used windows.location() and sent it to server and then verify if domain name matches. But in this method everyone can just pass it simply via fetch()
I've used allow only IP address, But if I push my website in production Other visitors get 403 error.
I develop back-end with help of Django and rustlang
It isn't possible. You can make it hard for entry-level programmers to reverse-engineer your solution, but there isn't any way to prevent access to your API if you are going to allow access to it from some public UI.
IP address-based restriction will not work here because your backend will receive the IP of the user. In this case, you will be blocking access to users, not to any UI. Even the host header verification doesn't work here as anyone can use a proxy server, i.e. NGINX, to override the headers and can fake the request to originate from an intended website.
IP address-based authorization can work only if API calls originate from a server and your API server receives the same IP address for each API call. But for your use case, it isn't applicable.
The older techniques like CSRF are useless too as anyone can easily retrieve the token and can send it. In short, if you make something public, it can be reverse-engineered. If you are accepting public registrations, there shouldn't be anything to worry about the registration source. You should think about solutions like email verification etc. to reduce the spam if that's the concern.
You could have your frontend solve a recaptcha and send the solution to the backend. Verify the solution before accepting the request. It is still possible to bypass although a bit harder.
Here is my little API with two URL :
/api/location/list -> GET
/api/location/detail -> GET
I'm looking for a process to secure this service with authentication. For now, it can be accessed by only one user (me).
I think oAuth is too complex in my case and I found this resource for designing a simple API.
I understand the principle of private/public key and HMAC but I have a big concern about this :
Say my webservice is consumed by an ajax request with GET verb. I have something like /api/location/list?apikkey=userid&hash=abcde.
A end user can easily sniffed the network during the request (via a simple chrome console), capture full url and access directly to the service multiple times (I think it's a case of replay attacks).
Differents resources talk about timestamp or nonce to make a request unique but I'm a bit lost with implementation.
Any ideas ?
You can try JWToken auth specs, simpler than Oauth, but avoid authorization data as url parameter if possible and use Header's request instead.
If needed consider also ssl encryption at tcp level.
Perhaps you could try to use a token-based approach for security, as described in this blog post:
Implementing authentication with tokens for RESTful applications - https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
The idea is to authenticate to an authentication resource (that can be part of your application) to get temporary token that can be refreshed with a refresh token when expired.
With the use of HTTPS, it seems to be appropriate.
I think that it depends on the security level you expect. Signature-based authentication (the AWS approach) is great but is a bit complex to implement by hand.
Hope it helps you,
Thierry
I'm using Django Rest Framework and Token Authentication. Everything works great so far.
http://www.django-rest-framework.org/api-guide/authentication#tokenauthentication
But I'm realizing that anyone could create a third party app that hooks into my API. There'd be no way for me to detect it or stop it.
Am I missing something? I followed the directions, and I:
Send "username=blah&password=blah" to https://example.com/api/auth/, and receive a Token in return. Anyone could do this from a third party app.
That token is passed in the authentication header to retrieve data from the API. Anyone could do this if they have their user token.
Even if a user knows their own Token, I only want them to be able to access the API through the official native app.
1. How do I secure my API (using Token authentication) and make sure that only MY apps can connect to it?
2. Could I include some kind of secret key in a header? I'm using HTTPS in production, are headers as well as form data (username/password) interceptable/readable? (By the person running the app).
Still learning, thank you.
Perhaps I don't understand you question fully, but:
yes, everyone with a username and a password in your application can create tokens, if you added obtain_auth_token to your urlconfig (what you don't have to).
So you can:
only give your apps username and password
or deactivate the obtain_auth_token view and create the tokens in the admin or manually.
To answer your HTTPS question:
HTTPS encryption is between the client and the server and lies between TCP and HTTP. So everyone in between (a man in the middle) can't see any headers, data, or even the path. When using SNI the hostname (Host header) is visible, but nothing else.
Hope this helps a little.
I need to centralize authentication to my rest web services and make this authentication the same for all of our webservices. So I started writing an external web service to take care about the authentication.
To keep compatibility, since the authentication was performed using a HMAC signature (signed using a private key) alongside the single request (so there is no token of any sort) I thought to make all web services to send the HMAC included inside the incoming request and the StringToSign (a representation of data used to generate the HMAC).
So the Authorization service can (knowing the private key) try to compose the same signature, if it matches then answers with 200 OK and with a JSON object saying "authorized".
All this communication happens over HTTPS, but I'm trying to figure out what could happen if someone would intercept or modify this answer, making a 403 Forbidden to become 200 OK...
Should I use some sort of way to recognize this is the original answer? If so, what could I do?
I do agree that ssl certificates released by CA's are secure, but how could I make sure my HTTPS layer has not been compromised allowing an attacker to modify authorization responses?
P.S. please provide some standard solution if any, I don't want it to be related to the technology I'm using right now, since each service may use its own stack and I don't really want it to be .NET or something else because there's a proprietary implementation for the authentication mechanism.
All this communication happens over HTTPS, but I'm trying to figure
out what could happen if someone would intercept or modify this answer
This is what the S in HTTPS is for: SSL guarantees integrity of the message. If the attacker forges the request, the client will notice it.
You can ask the experts at #security.
I consider myself newbie when it comes to securing my web applications.
I have built a website which updates the webpages regularly through an AJAX call. The Ajax call returns a decent JSON object to be used at the client side.
There is a simple problem I need to overcome: How can I prevent other people to use the same AJAX call without permission? What if they build a website, AND at the client side they allow their users to make the same AJAX call to my servers and grab what they need.. AND THEN parse it to their own needs at the client side?
I cannot put an extra layer of security like user authentication.
They won't be able to actually do this from the client directly because the browser will prevent cross domain AJAX requests for anything other than JSONP (scripts). That said, they can proxy it on their server if they want so it doesn't buy you much.
ASP.NET MVC has an antiforgery token mechanism that you should look at for inspiration. The basic idea is that you use both an encrypted cookie and an encrypted, hidden form input containing the same data that you write to each page that you want to secure. Do your AJAX calls using a POST and make sure to send back the form input. On the server-side decrypt the cookie and input and compare the data to ensure they're the same. Since the cookie is tied to your domain, it will be much harder to inject in the request that is being sent back. Use SSL and regenerate the cookie/input content periodically to make it even harder to fake the cookie/input.
You can check the HTTP_REFERER http header and see if the request originates from your page. This can however be spoofed, so don't think of it as a bulletproof solution. The best counter-meassure is user authentication, really.
You can't. That's because you can't differenciate between an AJAX call from your web app and another user's webapp.
Here are some things that might help a little bit.
Obscuring/encrypting your AJAX response. This fails mainly because you have to include the decryption code in your app as well.
Check the IP origin. If the IP didn't access your server before, you can assume that the AJAX call is not from your website. This doesn't work if a) the user switches the IP while being on your site / timing out or b) if another website sends a fake http request first before using your AJAX API.
Another idea would be to send Javascript instead of a JSON object. The Javascript should contain all the logic needed to update your website, and of course could check if the website is your own. (window.location). That has some disadvantages though: more work for you, higher traffic load and it can be broken anyways.
I don't think it's a bad thing actually. Another website could have just as easily scraped the info from your website.
If by "stealing" you mean getting some content from your website (using HTTP GET), that's more or less the same problem as hot-linking. You could have some basic protection technique using the HTTP Referer header (it can be worked around, but it works in most cases).
The other problem you have (making sure the requests come from your application) have to do with CSRF (Cross-Site Request Forgery). There are various protection mechanisms against this, mostly based on embedding tokens in forms for example.
You could potentially combine the two approaches, although the real protection against getting the content would come from user authentication (otherwise, the other site could also get the page from which you're delivering those tokens and proxy it).
(In addition, techniques that rely on remembering the IP address would probably not work well in the whole web architecture: it might cause problems if you get a pool of proxy servers or if the client is a mobile device that may change IP address between various requests, which would be perfectly legitimate.)