Our application uses AngularJS and consumed Web API in the backend. This is only internal application and authentication used is 'Windows' mode only. We are using custom authorization(role-base) to limit the access/execution of the application web api methods.
My question is do we need to add ValidateAntiForgeryToken attribute for those web api action with HttpPost and HttpPut attribute? I never use this ValidateAntiForgeryToken before as I was only involved in internal web application (local intranet only). Please guide me when/how to use ValidateAntiForgeryToken.
ValidateAntiForgeryToken protects your users from malicious web apps that send a POST request to your web app unbeknownst to your user, known as CSRF. Still the request would succeed since it's coming from your user who actually has permission to do so.
This is irrespective of the actual authentication mechanism, and is in fact a higher risk for automatic single-sing on that you have with Windows authentication.
If your internal web app is worth the effort, a targeted attack could trick your users to visit the attacker's web site that in turn sends the POST request to your web app.
My take is that you should use ValidateAntiForgeryToken even in this situation as a defense-in-depth measure.
Related
I am creating a public facing SPA web application using React js.
The backend for this application are the endpoints available under Azure APIM. I would like to restrict the access to these APIM endpoints in a way that they are only accessible from my react app.
As the react app will be rendered in the user's browser, I cannot have any IP restriction on my APIM backend inbound policy, as the application could be accessed from anywhere ( public facing). But if anyone gets access to the API url by inspecting the network traffic in the browser , my backend API's become vulnerable.
How can I restrict that APIM endpoints are only accessible from the react app ?
I have tried using CORS policy to allow my domain , but still tools like POSTMAN are able to access the endpoints.
The short answer is you cannot fully prevent people from hitting your public API endpoint on their own.
The longer answer is that you can put protections within your API config so that this isn't a concern. If all requests need a valid user authentication token, for instance, it doesn't matter if that valid request comes from your React UI or an errant user's terminal window. Check out some best practices on protecting your API endpoints, and it will hopefully answer your question.
You can't. At best you can obstruct the user by making it harder to replicate a proper request to your API. Ultimately there's no way to identify whether or not a request came from a browser or some other tool though.
It's up to you to construct the API in such a way that the user can't abuse it by limiting the user to only perform actions that they should be allowed to make. If you are concerned by a user overloading your API you can add a policy to APIM to apply rate limiting (e.g. by IP).
It not be possible to prevent attackers from inspecting HTTP traffic and the vulnerable calling endpoints.
You should implement authentication controls on API. Whenever a user opens a new session on you SPA, the API grants that user a token that is valid for a fixed amount of time (~30 mins). Ensure that the API checks if that token is valid for each request.
I have developed an AngularJs website, Android & IOS mobile apps. I am using https protocol to make my web service calls more secured. I am using OAuth flow for user authentication process. Once authentication process completed, OAuth token will be sent as a response to client apps.
Anyone can get access to server resources (upload/download user files) using this OAuth token from API response. So the system is not fully secured because it is difficult to check whether the request coming from my app or outside of the app.
If someone found the OAuth access key returned from my service, they can use them to upload/download resources from outside of the app. Server resource should be more secure as it contains more sensitive user records. Please check the below image to understand the workflow. Other programs section refers to custom batch scripts, other client apps, 3rd party tools etc..
How can I restrict my REST web service to send failure response if anyone tries to access it from outside of my app?
Please provide me the way to secure my web service and server resources by resolving these security issues.
I developed a windows mobile application which connects back to my web services hosted on internet to sync with the server data.
I didnt put any control for CSRF on mobile application, Is it required to have a CSRF protection on native applications? If yes why?
** My application is native application not on web browser.
Is it required to have a CSRF protection on native applications?
No, if your mobile application is the only type of consumer (e.g. no web browsers) and your mobile application does not make web requests to other domains then by definition CSRF is not possible as there is no cross site request to counterfeit.
CSRF protection would be on the web server side, not the app, although you can help yourself by setting a cookie from the server on login and adding that cookie to the header of your requests from the native app.
You application will most likely need to be CSRF aware (if you've implemented protections on the backend).
For instance, a general best practice is to supply a token on each request that will be used on the next request to ensure no duplicate requests can be made. Your mobile app will need to be able to get and use this token (again, assuming you've implemented this on the server side).
It really depends upon if your site can be accessed by a human AND/OR the authentication method that you are using for the web site.
If a user can login in any way to this web site that is hosting your web services via a browser then while the user is logged into the site, the answer is yes because CSRF takes advantage of the fact that the browser will send along session and other cookies when the web site is communicated with due to the fact that cookies are automatically added by the browser for all request targeting the same origin regardless of which web site is sending them.
If your web services can be accessed directly via NT Authentication then as long as you are logged into the network, the answer is yes. The reason is because the attacking web site that is using malicious JavaScript is still accessing the web services as YOU regardless of which site is sending the request.
Finally, if there is absolutely no way to login to the site via a browser and you are not using NT Authentication, SilverlightFox's answer is correct. The reason is because there would never be a Session cookie for the site so there is nothing to send when the CSRF attack occurred.
The Fix:
For web, this is fixed via an anti-forgery token, which is sent back with put and post verbs (although you can do it with all verbs). A malicious web site could try to send a request and would certainly pickup your session cookie, but the absence of the anti-forgery token in the put/post causes it to fail.
For mobile, patwhite above suggests a fix, but it would require different web service end points for mobile vs web due to the fact that it is a different strategy for handling the problem.
I'm trying to figure out how to implement the following authentication flow:
The user accesses a web application (most likely to be written using Ruby on Rails) and authenticates (e.g., username/password).
The client consumes data via AJAX provided by a RESTful API built on Google App Engine (Python, webapp2).
Requirements:
Only users authenticated in the web application (Rails) should be able to access the API hosted on App Engine.
Users can have different roles in the web application (Rails), and the API (App Engine) needs to know what roles are associated to the given user to restrict access to certain data.
The client should be able to call the API (App Engine) directly via AJAX, without routing all requests through the web application (Rails).
I'm looking for suggestions on how to implement such workflow. Should I use OAuth (or OAuth2) for accessing the API? Should the OAuth provider live on App Engine and the web application (Rails) ask the API for a token on behalf of the user? If so, what is the best way to allow only the web application (Rails) to request OAuth tokens? Or should I consider a completely different strategy?
Any suggestions are greatly appreciated. I'm also looking for suggestions of libraries to implement OAuth in the context above.
I suggest you use caution if you are considering implementing an API built on the Google App Engine using OAuth for your security layer. I am currently involved in a project that is struggling to solve exactly this problem. The OAuth layer over the GAE is still new and considered by Google to be "experimental". Google's documentation is minimal at this point. What there is begins here. I wish you the best if you try to proceed, and I will do my best to offer help if you do.
My solution to this same problem was to write my own three-way authentication (like OAuth):
After the user is authenticated on the RoR server, it responds with a temporary token. This token is stored on the RoR server, is good for 60 seconds, and contains the user's roles.
The browser sends this token (using AJAX) to the webapp2 server. It's like logging in on that server using just the token.
The webapp2 server forwards the token on to the RoR server to make sure it is valid.
The RoR server makes sure the token hasn't expired and immediately deletes the token to prevent duplicate requests. If the token is valid, the RoR server responds with the user's roles.
If the response from the RoR server is good, the webapp2 server responds to the browser's AJAX call (in step 2) with a cookie indicating that this user is now logged in. The session should contain the user's roles.
Subsequent requests to the webapp2 server will include the cookie so that server can respond according to the user's roles.
We're writing a Desktop application that relies on Google Appengine to authenticate the user and retrieve and store data associated to it.
The way we'd like to authenticate the user is that on launching the application the browser is launched at the login url for our application. Then the user logins there, and then the application makes restful calls without any OAUTH object, but re-using the browser session. I'm questioned that this won't work, since we cannot so transparently use the browser session. Is that correct?
Any alternatives beside authenticating from within the app using the ClientLoginApi?
I'm aware of:
How do you access an authenticated Google App Engine service from a (non-web) python client?
The only way to do this is if you can capture the authentication cookie used by the browser, and send it yourself. Obviously, there's no browser- or platform- independent way to do this.
A better option would be to use OAuth, with OAuth for installed apps to obtain the original token.