Facebook has done great work on preventing eavesdropping (with tools like Firesheep) by supporting https on all facebook.com pages, but does not provide similar levels of security for 3rd party sites.
Right now it's possible to eavesdrop the traffic from a 3rd party website which is using the Facebook JS SDK and get a user's signed fbsr_APP_ID cookie which a website should use to authenticate their users.
Is there a way to set this cookie with the secure parameter so that it's only transmitted over HTTPS connections?
I have read both the documentation and the JavaScript SDK source code and it doesn't seem possible. So if it's not possible, which other authentication method would you suggest to avoid eavesdropping of this cookie?
I think I'm too late for the bounty, but I'll happily take the "accepted answer" :)
As noted in the remark, on FB.init you specify, whether you want the facebook JS SDK to set cookies for you with the cookies option, it even looks like by default no cookies are set: https://developers.facebook.com/docs/reference/javascript/FB.init/
Then afterwards use your own javascript to store the fbsr_APP_ID any way you want (secure cookie, client side storage, etc).
Related
I don't know if this is the right platform to ask this kind of question,
but I have an app that is separated between frontend (Angular) and backend/API (Nodejs). Now the API exposes public endpoints to be used by the frontend. Now how do I protect the API from being used or exploited by other parties and only keep it to my Angular app? I thought of using an HTTP only cookie but it seems its visible when someone opens the developer's tools on the request's headers.
I am completely out of ideas, thanks in advance.
There is no way to make your site 100% secure but you can slow attackers down, or convince them on to a less secure site if you cover the owasp top 10 and have some transport protection.
Transport protection
HTTPS: either use a solution with https already configured, like heroku or now.sh or use letsencrypt.org
Authentication - There are loads of solutions and you would need to figure out how important the data is you are trying to secure. JWT is a good starting point as it is the easiest and relatively secure.
OWASP attacks.
The OWASP top 10 is here:
https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
You can cover the majority of the list by using a library such as JOI, https://www.npmjs.com/package/joi and setting up the schemas so you only allow input that is absolutely necessary. Use whitelists of valid parameters rather than allow any string.
The only other precaution I would take is to use the npm library helmet, https://www.npmjs.com/package/helmet. This covers most of the XSS points
Those are probably the main points you need to cover, that will deter most opportunistic crackers
You can secure your API with a token using OAuth2, I don't know in angular to much but the best practice is to secure the nodejs with JWT Token.
Helpful link Creating an API authenticated with OAuth 2 in Node.js
Beer Locker: Building a RESTful API With Node - OAuth2 Server
--
i have implemented the tokken based authentication in my project instead of the cookie-session based authentication. So, in jwt(jason-web-tokkens), every time is send req to server,I in headers attach the tokken and send it to server which validate it against the secret is used in generation the tokkkne in the first time and send me the response. Now, i have concern about it, first the tokken is saved in the local storage in browser.although the tokken is hashed but what if the hacker just take that tokken from storage and use it?
can anyone tell me how it stop the CORS attack?
I'm confused and cannot find any reliable answer online.
By CORS I think you are referring to XSS attacks? If so, the best way to prevent XSS is to secure your app against untrusted input. That is easier said than done, here is some information on that:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
The easier way to prevent XSS is to store the token in a Secure, HTTP only cookie. This means that the Javascript environment cannot touch it, and it will only be sent over secure channels.
Nothing comes for free though :) If you put the token in a cookie, you will also need to setup a CSRF prevention strategy:
https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet
This can be a lot to take in!
I work at Stormpath and I recently wrote this blog post that covers these topics: Token Based Authentication for Single Page Apps (SPAs)
I'm writing an API that will be hosted without SSL support and I need a way to authenticate the requests. Each client would have a different ID, but if requests were authorised with that, anyone with a packet sniffer could forge requests. Is it possible to make a secure system WITHOUT relying on SSL?
(Some thoughts I had included OAuth, could that be implemented?)
Many thanks
Have each client cryptographically sign its requests with a client-specific key. Verify the signature on the server.
Using cryptography pretty simple. The main challenge is setting up the clients' keys. It'll be hard to do that securely without using SSL. There's no information in the question about how you set up client IDs, so I don't know if it's secure enough to set up keys at that point as well.
It's also going to be a problem if you serve the client code without SSL.
But hey, it's just an API you're building. Maybe the code that interacts with it is served over HTTPS. Or maybe the code is stored locally on the client.
I feel like a lot of people are going to complain about this answer though.
I'm developing a web application using Java EE and some open source components (Spring, Struts 2, jQuery, and so on). Some of my web pages require authentication (Spring Security) and other not. I write some REST APIs (Restlet) and I use them from my pages by AJAX calls (jQuery). I know that other web sites can not use my REST APIs unless I enable CORS and this is what I want.
However any non-browser client (curl, Java applications, and so on) can call my REST APIs: how can I forbid this? I can not use authentication for all REST APIs because I use some of them in web pages that should not require authentication. I know that some APIs (like Facebook SDK) require an application-id in order to enable calls, but anyone can steal the key from the Javascript code included in my web pages.
I would like to recognize from the server side if an HTTP request has been sent from a browser or other client applications in order to apply some kind of authentication only in the second case. As I concern, any client application can set any HTTP header, so I can not HTTP headers, can I? I think that my problem should be a common problem, so maybe I miss something.
There's nothing you can do.
Most folks are worried about unauthorized users using their applications. You're worried about unauthorized programs.
Yet everything that a program needs to communicate with your server, it will be told (by the server as in a token, or by the user as in a credential).
Why are you afraid of "non-browser" clients? Why do you care what client they use? How is a non-browser client different than a normal browser for your use cases?
Answer that question, and you'll find better answers.
Are you afraid they'll "screen scrape" your site, quickly download it with something like wget? Then you can put in some server side rule gating their access (if IP x.y.z.w makes more than Q requests per BLEEM of time, then discard request/sleep 10s/send content REALLY slowly).
Those kinds of measures are what you have to do. You can't "secure" the client, it's not your client to secure. You have to secure your server, and address the concerns head on.
Remember rule #1 of client/server design: "Never trust the client". On the internet, no one knows you're a bot.
Regarding this security issue: http://techcrunch.com/2010/10/24/firesheep-in-wolves-clothing-app-lets-you-hack-into-twitter-facebook-accounts-easily/
Is it true to say "any time a user logs into a site, and isn't redirected to SSL/TLS/HTTPS connection, that the session cookies are vulnerable"?
What is the best solution to protect a Facebook credentials, and how does it work?
Is there any way to have a secure session and not have SSL/TLS? In other words, is there any way to make it so that cookies on one machine can't be replayed on another?
The reason the last question is important is because Google AdSense does not support SSL/TLS and therefore will force the designer to expose all cookies. This will in turn affect every site that relies on AdSense
The problem is the cookies and send in clear on the network if you don't have SSL/TLS.
Anyone listening to the TCP/IP traffic can read unencrypted data and can read you cookies.
When you have them you can copy it on your own computer and it will work...
You need SSL/TLS !
When you are transmitting data in the open (unencrypted) there is NO WAY to protect your information, especially not using a cookie which is a well-known and widely used protocol for storing insensitive user information. You may try tricks and hacks to assert that only the person to whom the cookie was issued is the one who can use it, but that is not what cookies were designed for. COOKIES ARE NOT A SECURITY FEATURE!
If you want privacy, use encryption. It's as simple as that. SSL certs are cheap (as low as $10 per year). If security and privacy are a requirement, there is no excuse not to use SSL.
For your own sites, you can design cookies to be more secure: http://jaspan.com/improved_persistent_login_cookie_best_practice
But because Facebook hasn't done this, the only option if to use SSL.