I have created the sign up Api in Django Rest FrameWork without authentication or any permissions and i want to use is it in mobile app.
my question is this api secure???
any person or Robots that access to the SignUp Api Url can create Account nonstop.is there any antibot or something???
If you implement the api without any type of security. Depending on what you let the user do with the api, which endpoints they can hit.
Is there any server side security?
You can implement Jason Web Token: simple JWT
You can check also django throttling : Throttling
You can also research on how to limit api calls from a device.
You can implement a check which will allow only one sign up from a IP address for a specific time so that your API doesn't get brute forced.
And Implement ReCaptcha as well
Related
Subscription based iOS app I'm building uses Cloud Run service invoked via HTTPS request.
How can I make sure that the request can only be invoked by app owners(from the app)?
I've looked at Google Sign-In authentication, but I don't think it is applicable in my case as only those subscribed to the app should have the access, not just those with Gmail account.
I think without a Google Sign-in involved, your question has nothing to do with Cloud Run and can be generalized as:
How to send requests to to a backend app only from its mobile app?
So I'll answer that.
You'll find out that you need some form of "authentication" to prove that you're on a mobile app as a "user". To achieve that, you need some form of sign-in.
You may try to ship a secret (like a token or private key) in the application and use that to authenticate, but this will be susceptible to:
exfiltration of the private they from the application bundle through reverse engineering
applying a man-in-the-middle attack to the HTTPS request (and therefore the token) by trusting a root CA on the device and using e.g. mitmproxy to decrypt the request as plaintext.
In reality, there's no way to fully secure iOS/Android <=> backend communication that. Even the largest apps like Twitter, Instagram etc have their APIs reverse engineered all the time and invoked from non iOS/Android clients as the requests can be spoofed.
If you want to authenticate your existing users, you should figure out how these people login to your app. This could be simple username:password in Authentication: Basic [...] header, or something more complicated like OAuth2 which is what apps like Facebook, Twitter implement under the covers for their mobile apps.
Then you would validate that Authentication header in your Cloud Run application code yourself.
So again, I don't think this is a problem specific to Cloud Run, or any cloud provider.
If your goal is for your API to only be called when your users are authenticated in your app, I would recommend implementing one of the two solutions described on this page:
Using Google Sign-in or Firebase Authentication
I have a Django application that currently stores user credentials and performs authorization and authentication. I am in the process of breaking off the front-end into an Angular SPA and converting the backend to a REST API. My Django API will live as an Azure API app protected by Azure API Gateway. I would like to remove the authentication piece from Django and allow users to sign in using OpenID Connect through either Google or Microsoft Account. What I would like to happen is this:
When a user visits the site, assuming they have never registered with my app, they will have the option to sign in with their Google account or Microsoft Account. If the user decides to sign in using their Google or Microsoft account, (this is where I'm confused and why i'm posting here ... ) I think what happens is the API Gateway performs the authentication, generates a JSON Web Token (JWT), and sends that token back to the Django API. Django receives the JWT, decrypts it, and checks to see if there is a user account matching the email address in the JWT. If there is not a user account, Django will add a user to the user accounts table (not storing a password). If there is a user matching that email address, then Django allows the user in.
All that said, I guess my question(s) are:
Should I do the authentication at the API Management Gateway or should I do it at the Azure Web API?
Can I use Django's built-in authentication system to do what I want or is that not needed?
Am I over-complicating all of this? Is there an easier way to do this? All this seems like a lot of work.
Is OpenID Connect what I should be using (instead of Oauth2)? I have no experience with either.
Azure API Management does not actually provide any kind of JWT issuing mechanism, so you'll have to implement that yourself. The end points for doing that may or may not be exposed via API management.
What possibly gets you confused is the fact that the APIm Portal supports various indentity providers, like Twitter or Google, to sign up for the API. But these are not your application users, these are for the API Portal Users.
What you can do with the APIm Gateway is to validate subsequent calls to your backend API that the supplied JWT token is valid (using the <validate-jwt> policy).
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
The whole API is built on top django-restframework and django-oauth2-toolkit. I want to add API endpoint which will allow client applications to register users.
So, if I want to register user I have next options:
I have to authenticate before POSTing request (does not make sense at all)
to open api/users/register to everyone (is not secure).
What I want to do, is to grant access to this endpoint based on oauth2's client_id and client_secret. Is there straightforward way to achieve this?
Thanks
This is a similar situation to the one raised in this question:
Javascript Calling a Rest API with App Name and App Password - How Can i Secure it
Here is the architecture overview:
The site is Html5/jquerymobile
It contacts what I call a "Wrapper" service.... This is a REST API I wrote in C#, to contact another 3rd party REST API. I do this because there are credentials in the Header and the API uses Basic Authentication. Credentials are therefore not publicized as they are only known server-side.
My "Wrapper" service does not currently implement any additional security. It is currently accessible from anywhere. The easiest and quickest way to lock it down is to restrict by IP, so no other IP anywhere except the server can actually contact my wrapper service.
The questions:
Is the locking by IP the only way to ensure that the API won't get hammered if it was otherwise accessible from anywhere?
If I convert this using Phonegap (which I have... and deployed successfully on Android), obviously the native app won't work if the web service is restricted.
Is there a way around this so I can allow traffic only from the mobile app, and not from any other source? I'm thinking along the lines of MD5 hash or something that could be sent to the wrapper API.. but unfortunately I'm thinking that info can easily be "sniffed".
Is my only viable option here to release the app as a web app, forcing browser use, thereby removing any concerns about allowing my web service to be hammered??
I believe the answer to this is a combination of a user token and encrypting the message through SSL.
The server can issue a valid user a token so we can identify him in future requests.
Encrypting it via SSL will ensure that this token cannot be sniffed.
https://security.stackexchange.com/questions/12531/ssl-with-get-and-post