Why isn't there a logout button? Why no list of "websites you're logged into"? Is it because of some issue with the HTTP specs?
Life would be much easier for web developers if they could actually rely on HTTP auth ...
As far as HTTP is concerned, it is stateless. One of the main reasons why Internet is scalable.
No technical reason. I suppose if anything, the auth UI is neglected because fewer and fewer web sites are still using HTTP Basic Authentication, trending more towards various cookie-related login schemes... precisely because the auth UI is so poor!
One could probably hack together a Firefox add-on to do it quite easily, which would be the quickest fix. (And the same goes for the other question with the poor file upload UI too.) I'd use it!
Have you entered a bug report for major browsers ? (At least, ones with bug trackers, Firefox, Chrome (Chromium) etc.
List of open HTTP Auth sessions would be useful.
Because it's not the browser that "knows" it's logged in. It's the server which authenticates the browser on every request. Every server can have different authentication mechanism - using different names and content for the authentication cookies, basic authentication, etc.
Related
In the documentation, there is a large, bright red warning:
Never use API flows to implement Browser applications!
Using API flows in Single-Page-Apps as well as server-side apps opens up several potential attack vectors, including Login and other CSRF attacks.
The documentation does not elaborate on what these attacks are. If I properly secure my application by storing session data on the server, by allowing only the server to access this API, and by implementing my own csrf protection, am I safe? If not, what attacks am I opening myself up to and what additional measures should I take?
Certainly, there must be a way to secure my application without tearing down the running javascript vm then sequentially being redirected three times just to view a login/registration page. For modern apps, I think users may expect this discontinuous transition for successful authentication, but I don't think it's necessarily expected for just viewing the login/registration page.
There are two ways to use Kratos.
From a WebApp (browser)
From a Native app (iOS, Android...)
The first way is using browser redirects and they set csrf tokens.
The second way does not set csrf tokens since there is no browser involved.
That's why there is a warning stating that any sort of "browser" related application should never use the methodology from the native app flows and vice versa!
For example here is how you initialise the login flow for API clients (native apps)
https://www.ory.sh/kratos/docs/reference/api#initialize-login-flow-for-api-clients
And here is an example of how you initialise the login flow for Browser clients
https://www.ory.sh/kratos/docs/reference/api#initialize-login-flow-for-browsers
The selfservice configurations are for your browser redirect flows (so Browser clients).
All credit for this answer goes to https://github.com/Benehiko.
For more details about the warning, please visit the kratos channel.
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.
I need to implement CSRF protection for my site. So I started implementing this for all forms from my site, but I have problems with implementation of it in browsers extensions (Chrome, Safari, Firefox). I have no ideas how to do this for posts from my extensions(forms and ajax posts). Had anyone implemented this ever?
Well, here are some things that I saw people actually use - in my function as addons.mozilla.org (code) reviewer:
Design a proper API. There are tons of resources on SO and the web, e.g. detailing how to properly build e.g. Restful APIs and secure them against CSRF. The thing to keep in mind is that extension APIs in contrast to regular web pages provide XHR that either doesn't care same-origin or let you define a set of locations the extension is allowed to access. Hence extension-specific APIs not need to implement CORS, which shrinks the attack surface on such APIs quite a bit. Of course, it would be better to go the extra-mile and ensure your API is secure even with CORS.
Designing a full web API can take quite a lot of time. I saw people build a very minimal one: The API consists of a single method to get the CSRF token to be used with the regular not-very-APIy existing forms.
If you cannot implement a proper API, because e.g. it's not your site/code or you simply lack the time, resources and/or skills to learn about and then design and implement an API, there is still another way: Just web-scrape the site (XHR + regex usually) and get the CSRF token that way. Again, extensions do not have to abide same-origin, so web-scraping is always a possibility, while web sites cannot do the same thing unless allowed by CORS.
Almost forgot: Some extensions are nothing more than a button that will open a regular webpage on the server - not necessarily in a regular tab, but often in some kind of panel as provided by the extension API you're dealing with.
I have a website protected by basic auth, so when someone hits it, they get a standard username/password box. This website is accessed often from shared computers.
Is there any way to prevent the various "Remember my Credentials" functionality on browsers? I would like to prevent any browser from saving this username/password in any client-side repository.
I realize this is purely a function of the browser, but is there any commonly-accepted HTTP header or any other method of asking a website not to do this?
The answer is no. I'm really sorry but even if you could do this how would you stop an independent add-in from scraping web sites for username and password boxes and then storing that information.
Even if this were possible in code it could be easily circumvented by simply ignoring any directives you give. Thus rendering such headers pointless.
As stated before it is not possible to circumvent a browser feature it could easily save the credentials before it sent the POST thus stopping anything on the server from preventing it being cached.
Regarding cross-site request forgery (CSRF) attacks, if cookies are most used authentication method, why do web browsers allow sending cookies of some domain (and to that domain) from a page generated from another domain?
Isn't CSRF easily preventable in browser by disallowing such behavior?
As far as I know, this kind of security check isn't implemented in web browsers, but I don't understand why. Did I get something wrong?
About CSRF:
On wikipedia
On coding horror
Edit: I think that cookies should not be sent on http POST in the above case. That's the browser behavior that surprises me.
Why wouldn't the browser send cookies?
Site A (http://www.sitea.com) sets a cookie for the user.
User navigates to site B (http://www.siteb.com). Site B features integration with site A - click here to do something on site A! The users clicks "here".
As far as the browser can tell, the user is making a conscious decision to make a request to site A, so it handles it the same way it would handle any request to site A, and that includes sending site A cookies in the request to site A.
Edit: I think the main issue here is that you think there is a distinction between authentication cookies and other cookies. Cookies can be used to store anything - user preferences, your last high score, or a session token. The browser has no idea what each cookie is used for. I want my cookies to always be available to the site that set them, and I want the site to make sure that it takes the necessary precautions.
Or are you saying that if you search yahoo for "gmail", and then click on the link that takes you to http://mail.google.com, you shouldn't be logged in, even if you told gmail to keep you logged in, because you clicked on the link from another site?
It isn't that a browser is sending the cookie to or from an outside domain, it's the fact that you're authenticated and the site isn't validating the source of the request, so it treats it as if the request came from the site.
As far as whether a browser should disallow that... what about the many situations where cross-site requests are desirable?
Edit: to be clear, your cookie is not sent across domains.
I don't know that there's much the browser can do in that situation since the point of an XSRF attack is to direct the browser to another point in the application that would perform something bad. Unfortunately, the browser has no idea whether or not the request it's being directed to send is malicious or not. For example, given the classic example of XSRF:
<img src="http://domain.com/do_something_bad" />
it's not apparent to the browser that something bad is happening. After all, how is it to know the difference between that and this:
<img src="http://domain.com/show_picture_if_authenticated" />
A lot of the old protocols have big security holes -- think back to the recently-discovered DNS vulnerabilities. Like basically any network security, it's the responsibility of the end-points; yeah, it sucks that we have to fix this ourselves, but it's a lot harder to fix at the browser level. There are some obvious ones (<img src="logoff.php"> looks damn fishy, right?), but there will always be edge cases. (Maybe it's a GD script in a PHP file after all.) What about AJAX queries? And so on...
The cookies for a site are never sent to another site. In fact, to implement a successful CSRF attack, the attacker does not need to have access to these cookies.
Basically, an attacker tricks the user, who is already logged in to the target website, into clicking a link or loading an image that will do something on the target site with that user's credentials.
I.e., the user is performing the action, and the attacker has tricked the user into doing so.
Some people have said they don't think there's a lot the browser can do.
See this:
http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
It's an overview of a proposal for a new HTTP header to help mitigate CSRF attacks.
The proposed header name is "Origin" and it's basically the "Referer" header minus the path, etc.