How do you do a jQuery Ajax call and authenticate the call prior to sending the request?
I have not logged in so have have to authenticate. Security is not an issue anyone can get access just need to authenticate. It just basic http authentication you can take a look at the API http://lighthouseapp.com/api/the-basics
Since you don't specify what kind of authentication you're using, I'm going to make some big assumptions that you have some sort of login page/action that you post the username and password to, using those as the parameter names. If you have other fields -- like hidden fields to prevent cross-site request forgeries, you'd need to include those as well. I'm also going to assume that you know you're not already authenticated. There are ways to detect this, but I'm not going to cover them. I'll further assume that you're posting to the web site's actions, not to some API that requires a separate type of authentication.
The first thing you'd do is generate a POST (I assume) to the login action with a correct username/password combination. How you get these is up to you. This will authenticate you with the web site and supply your browser with the appropriate authentication cookie to send with future requests.
You'll need to detect and handle an authentication failure. If your login action understands that it might be invoked via AJAX (using the HTTP_X_REQUESTED_WITH header is a good bet), then it can return JSON with a status setting otherwise you'll need to scrape the returned HTML to figure it out.
Once you have the authentication cookie, you should be able to make your actual AJAX request without any special handling.
If a user on your website is already authenticated, in most circumstances you don't need to do anything - auth cookie will get sent with your AJAX call. Otherwise, you can try HTTP Basic auth.
If you are trying to get javascript to do the authentication without any user interaction, don't.
Hardcoding your authentication logic into code available to the client could severely compromise the security of the API. If you are going to put the username/password into your javascript, why even use one at all?
If you have access to the API and can rework the authentication, you could try a tokening system for authentication. Just my $.02
Related
I developed an application using the MEAN stack, where a user can signup and login. When a user returns to the application after some time, I can recognize it using Express Session, but I want him to confirm its identity by typing the password (or a PIN) before giving access to the application.
So I make an HTTP call to an API (passing the password or pin) that will either return true or false to allow access to that page.
Is it possible that someone intercepts the HTTP call (e.g. via DevTools), intercept the returned value and edit it, effectively bypassing the security check?
Or even intercept the router variable and force a navigation to a specific page (not available otherwise)?
Does Angular have in-built securities to prevent this, or do I have to implement it myself (in this case, what is the best practice)?
Thank you so much!
EDIT: As #bsheps pointed out, implementing AuthGuard solved the second point, about manually modifying routes to access reserved pages.I still have to find an answer about the first point. Even when calling an HTTPS endpoint, can someone debug the code and the network requests to edit the response received from the server?
About HTTP security:
HTTP is written in plaintext and not secure. If someone intercepts your communication (Man in the middle attack), they can read your password/pin in plaintext. Additionally, they could also edit it since it is plaintext. For this reason passwords should be sent via HTTPS.
About angular router security:
It is possible to manipulate the routes in the URL. To combat this, you can setup an authGuard for your application that will verify the login before directing to specific pages.
Here is a straight forward example to get you started:
https://alligator.io/angular/route-guards/
Hope this helps!
I'm wanting to create a series of static HTML sites which will be hosted at on Amazon S3.
The static sites will have forms. My plan is to post/ajax submit the form data to a server side application hosted on a different domain. The server side application will store the data in a database for future reference as well as email the submitted data to the relevant person.
At face value this is simple, the HTML form just needs to POST the data to the server side script, similar to google forms/wufoo/formspree etc.
My concern is with the security implications of this. The post will be cross domain from the static site, which seems to make CSRF difficult to implement in popular web frameworks. I've read many blog posts on CSRF/CORS/Authentication but am no clearer.
From studying formspree.io's source code, it seems they check the referer and origin headers to verify the form submission is coming from the website it should be and a website that is registered. However I understand these can be spoofed?
As any javascript code on the static site can be read and reverse engineered, API style authentication seems difficult...
Or am I overthinking this, and if I post the form via SSL, validate the form data server side, check the referer/origin headers as per formspree it should be secure enough?
TLDR; For a static HTML site posting form data to a server side backend for storing in a DB and emailing, what security steps do I need to take?
Thanks in advance!
Optimal Solution
It appears that the optimal solution in your case is doing the following:
Implementing a Recaptcha.
Sending the request to a script of your own first, that validates the captcha and then forwards the request.
Adding Access-Control-Allow-Origin only your HTMLs' origins only. useful question
CSRF Protection
As a matter of fact, It's pretty difficult to build a secure application if you only have access to the client side. If the services you're posting to doesn't have a built-in CSRF system, It'd be a good solution if you add a recaptcha to your HTML page and create a simple php script that will receive the form fields, validate the recpatcha and submit the form fields to whatever destination you want.
A CSRF protection through a token would also do the trick and actually it's the clean-coding solution if you eventually submit to your own script first, still, it would be somehow difficult to implement it into static HTML pages. (You'll need to generate it through Javascript or a php script, store it in your session, then validate it in your backend script) but I'd recommend it if you are able to code it.
In both cases, you'll need to submit to your own script first and then forward the request through CURL.
Validating Headers
In your backend script, you can validate the referer and origin to make sure the requests aren't coming from a different source other than your HTML forms.
Summary
The recaptcha will prevent anyone from doing a CSRF attack against your users.
In case the attacker was trying to find a workaround the origin and referer checking, they might use something like CURL, the recaptcha will also prevent them from doing that.
The Access-Control-Allow-Origin Implementation will prevent attackers from submitting data to your page through javascript.
Submitting to your own script first will also prevent anyone from knowing where exactly you're submitting these data, which will make it harder for them to perform an attack.
Although the captcha isn't a very user-friendly solution, if you have the ability to code a CSRF protection system it needs to be done through either javascript, or sending an ajax request that generates a token unique to user's session then you can validate that token inside your other PHP page, but you'll need to implement the captcha to prevent spamming anyways.
On your server, you need some middleware to make sure that the request origin is one that is trusted. So if your static html site is www.mysite.com, make sure that on the server www.mysite.com is allowed access to your apis. As far as authentication goes, if you don't want just anyone accessing your apis, you need some type of authentication. Basic flow kind of looks like this:
User posts login data, server authenticates, server generates token and sends back to client in response, token gets stored on the client and set in the header with any requests being made. Then on your routes, you will need some middleware to check if a token is present in the request header, if so, allow access, if not, deny it.
Hope that clears some stuff up.
I've been tasked with creating an LDAP authentication on a front-end Javascript application.
I am extremely limited on time and have a very small toolset. The toolset is the front-end javascript application and an available C# application which I can make post and get requests to.
I was thinking I could simply make a call such as https://mybackend.com/authenticate
Where I would post a username and password.
And on the backend this would return whether or not the user was valid in the AD. Which I can then use on the front-end to ensure the user has logged in.
Is this approach extremely unsecure or does it have flaws? I'm thinking that if I am posting to the backend above not much will be exposed.
Any tips would be immensely helpful.
Is this approach extremely unsecure or does it have flaws?
This is not insecure, it's the normal way you would do it. One could add more security by adding a CSRF token, which would be validated on the server for any form submit.
And yes, you should send all the data over HTTPS, this will encrypt the payload.
What you are doing is normal for front-end JavaScript framework like Angular. As long as you use Https, you should be ok.
Only issue is how you will handle the subsequence page requests.
There are two ways to handle it –
Easiest way is to use ASP.Net MVC as login page, and use Cookie Owin Middleware. Since same cookie is sent back to server on API calls, you do not need to do any extra works. You can download my sample code at GitHub - OwinAuthenticationService.
Another way is to use Bearer Token in which you will have to send the same token back to server on every page request.
All method are insecure.
Especially without HTTPS.
But you can put the Authentications in the header of message and use a token generated with a key that only server know.
I am trying to handle following case, I am new to web-app world so please pardon my ignorance (if any):
Assumptions/Constraints:
I don't have any control over the web-app code base whatsoever.
Authentication is being handled at http proxy level.
Scenario:
User has authenticated with a web-app using SAML and has been accessing the web-app for quite some time.
His authentication token (or cookie) expires.
He submits a form (HTTP POST).
Server needs to perform the authentication workflow again, which requires a HTTP redirect.
Now, the requirement is to somehow resubmit the original HTTP POST, after completing the authentication workflow, automatically for the user. A couple of options I could think of are:
Use javascript injection to store the POST state in browser's sessionStorage and rePOST things after completing the auth workflow. But I couldn't figure how would this work if the original POST was done using XMLHttpRequest ???
Store POST state on server (or proxy) side and do an internal rePOST and return the result to the browser.
Are there any other options ??? It'd be great if we could avoid saving state on server side. How do people usually handle such scenarios?
TIA,
praddy
Generally the second approach is implemented.
You send the request to the server running the application, it preserves the POST data (actually the again doing the authentication does this), sends you to authenticate, redirects you back and POSTs the data again. This feature may already be present in your authentication infrastructure and just needs to be enabled, but that of course depends what you are running.
This feature is sometimes also referred to 'POST data preservation'.
What is the best way to determine if a request being made to my REST service originated from a web client. I know I can look at the user-agent, but my concern is that is very easy to spoof.
The reason I want to know who originated the request is because of the following. It is natively built into web-browser that you can't do cross-domain requests. Therefore I don't need to worry about the authentication, because I know the request originated from my website.
My site is built entirely in HTML and Javascript, any suggestions?
Or is there a good way in Javascript to store a hidden username / password I can use just for my website, without it being displayed to the public?
Thanks,
Adam
Anything put in the javascript can be found by using a debugger, such as Firebug, so even though it isn't visible to the user, it can be found by a user.
But, if the javascript first calls to a REST service to get an encrypted token, then the token, which has a timestamp encrypted within it, could be the password, so you then pass the username and token to call the rest of the REST services.
Your server could then validate that it had created the token and that it is not expired, and that the username matches what was encrypted in the token.
But, this depends on if you have any control over the REST service.
The reason I want to know who originated the request is because of the following. It is natively built into web-browser that you can't do cross-domain requests. Therefore I don't need to worry about the authentication, because I know the request originated from my website.
This is not a good assumption. For the reasons you already gave (easily spoofed User-Agent), anyone could make a request to your application. You can even disable cross origin policy in firefox and chrome from the client side - so even if you could verify the request came from a browser, it's still possible to get around your security measures:
Disable same origin policy in Chrome
There are a couple of standard ways to implement security for this kind of service (as James mentioned, assuming you have control over the REST service).
Use Basic Authentication - If your application is communicating with the WCF service via HTTPS, basic authentication is probably the easiest method. See this question
If both your website and your WCF service are implemented using .NET, and your ASP.NET web application is using Forms Authentication, you could share the Forms Auth cookie and use that for authentication. See this question