I'm logging into a website using PHP cURL -- it generates a cookie file once logged in succesfully.
$cookieFile = tempnam("/tmp", "curl-cookie"); // Cookie file to login.
The php script is being executed by an ajax $.get request to the php file.
Now since I'm logged in, i want to navigate (not really 'navigate', just directly make a $.post request) to another page, but i wanna do this in Javascript/Ajax; however the only way to stay authenticated for the page to load successfully is for the cookies to be read. I'm trying to figure out how i can set all the cookies in the cookie file into the header of the $.post request so i get the appropriate response and not a "you need to login" response.
I'm sure it seems a bit odd. But that's what I'm trying to do. Any ideas?
Also keep in mind, i'm trying to send cookies to another domain, not my own. Not sure if that is an issue...
If you are doing the authentication server side, gathering a cookie, that you would like to replay for further access, those access need to be done also server side.
From the client point of view, cookies are strored in the browser. For obvious security reasons, a webpage cannot modify the cookie storage of a client, hence you cannot "add" the cookie copied from your server, to any client, that you would like to be authentified.
The target website should expose a cross site js API, like Facebook, gmail or other such API, in order to identify your clients against it.
Related
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'm using Javascript and XmlHttpRequest to POST to another URL on the same site. Users must be authenticated to access the page where the Javascript runs, but I need to submit the POST to the second URL as a non-authenticated user (to prevent the server from running code which is always run for authenticated users). Is there any way to submit the POST so that it appears to come from a non-authenticated user (so the server doesn't pull the user's authentication information from their session and treat them as authenticated for the POST)?
For example, is there a way to open a new session just for the POST, or to change the session ID just for the POST?
Note:
I tried to explicitly perform authorization using credentials for a non-existent user, but that didn't make any difference.
If this can be done using ajax instead of XmlHttpRequest, that's an acceptable solution.
Unfortunately this can not be achieved only in JavaScript, so you will have to make some changes on your server. You have two options:
Either you mark your session cookie as HttpOnly, so it won't be sent together with your request. But this will mean, that all your requests are sent as unauthenticated user.
Second option is use of a subdomain for this endpoint. Cookies are sent with XmlHttpRequests only on the same domain to prevent cross-site scripting. So if you move the server endpoint from www.example.com/myresource to api.example.com/myresource, the cookie will not be sent.
I have a PHP app that renders HTML pages for a social media application that I'm creating. Then, JavaScript initializes and makes things interactive. The PHP side of things logs into a separate webservice with curl.
Now, I can't figure out a way to share the session started in PHP with JavaScript, so when I make a AJAX request in JavaScript to the data server, its authenticated.
Is there a way to share a PHP session with JavaScript? Or to share authentication initially created with PHP with JavaScript?
I would say it sounds like there is something wrong with your architecture. In my opinion, the web server itself, should be the only peer providing data to the client/browser. It's a two party conversation only.
When trying to hit a third-party server from the browser, you violate the browsers Same-Origin Policy, unless you specifically allow CORS by explicitly setting various request and response headers. - and you would only do so in very special situations.
The best solution might be to create proxy services at the web server, that can be hit directly (locally) by the browser. The web server can then (acting as controller) forward the data-request to the data server (model) and finally return the response to the browser (view).
You can read out the session cookie set by PHP (SID I guess) through JavaScript containing the session ID.
When you make a query, use
http://example.com/?sid=SessionID
I would like to know if the following is possible and if it is please guide me in the right path.
My site is x.com and when a user submits a form on my site an API call is made to y.com which returns a JS hash (yeah very outdated, I know).
You can see the call to y.com being made in FireBug with returned params. Problem is that Adblocker Plus is intercepting this content and blocking it from view. (Not good (displaying a message about ad blocker is not a solution (In this case the user is actually expecting the ad)))
Is it possible to have my server make the request to y.com server (without the user's client being aware) get the response on my server side, and then finally generate the page and with the response content in the body, and lastly render to client?
This is entirely possible. You could define an endpoint on your local rails app (x.com) and submit the form to that endpoint. Then use an HTTP library, I prefer rest-client, to then submit the form to y.com.
I am writing a single-page application with CanJS. For one of models, every time I save a new item, the application sends the normal POST request. However, there is a specific cookie that is returned in the HTTP response that I would like to send back to the server on GET requests when fetching an item.
All cookies specific to an application are passed automatically to server in request header. Make sure that the cookie which you want to send is of the same application.
This you can check by looking into the cookies of your browser. Make sure that the cookie which you want to send has Domain as your application name. Like all stackoverflow cookie will have domain value as .stackoverflow.com
You can refer to this tutorial which talks about creation and setting of cookie in JavaScript : http://www.w3schools.com/js/js_cookies.asp