I've been making some endpoints that all just have basic auth. The auto-generated Swagger UI looks nice, and users can use it in their browser by entering their credentials after clicking the green "Authorize" button.
Where and how are these credentials stored on the front-end?
By default, these credentials are stored in the browser memory and are discarded when the Swagger UI page is refreshed or closed.
If Swagger UI is configured with persistAuthorization: true, the currently active credentials are saved in the authorized key in the browser's local storage. The saved credentials will be pre-applied after refreshing or reopening the Swagger UI page. Clicking "Logout" in the Authorize dialog deletes the corresponding credentials from the local storage.
Note that when using incognito / private browsing, the local storage of private tabs is cleared when the last private tab is closed.
The boss is asking whether or not this is secure. I think in other S.O. posts it recommends that storing secrets in the browser's local cache shouldn't be done. Do you know if the secret is at least hashed? I was trying to look in the source code for my answers but not having much luck.
If you mean persistAuthorization: true, I personally wouldn't use it in production. To me, this config looks more like a thing for dev/test environments.
I don't know how (in)secure the local storage is compared e.g. to cookies or the browser's "Save Password" feature. If you find useful resources, leave a comment.
Swagger UI's auth-related code is here and here. The persistAuthorization config was added in this PR.
The saved credentials are not hashed or encoded, probably because 1) Swagger UI code runs only on the client side and client-side encoding/decoding of secrets doesn't make much sense; 2) it needs the original (unmodified) credentials for "try it out" requests.
Related
I am preparing to work on a project where I need to display a dashboard from an online application. Unfortunately, the use of an API is currently not possible. The dashboard can be embedded in an iFrame. However, when it is displayed it will prompt the user viewing the dashboard to login to an account.
I have one paid account to this service. Are there any rails gems to login to the service before the iFrame is processed?
Or would a proxy within my rails app be a better route to go?
Any pointers are appreciated!
Neither a Rails gems nor a proxy within your rails will work and they same have the same limitation.
They are both running on the back-end, server side.
The authentication you need is client side.
Unless you mean proxy the ENTIRE thing, the auth request and all subsequent requests and user interactions with this dashboard. That should work but (see below)
The way authentication works (pretty much universally) is: once you log in to any system, it stores a cookie on your browser and then the browser sends that cookie for every subsequent request.
If you authenticate on the backend, that cookie will be sent to your rails code and will die there, and the users browser will never know about it.
Also - it is not possible to do the auth server side and capture the cookie and then have the user browse the site with their browser directly, for two reasons:
Sometimes auth cookies use information about the browser or HTTP client to encrypt the cookie, so sending the same cookie from a different client wont work
You can not tell a browser to send a cookie to a domain different than your own.
So your options are, off the top of my head right now:
If there is a login page that accepts form submissions from other domains, you could try to simulate a form submission directly to that sites "after login" page. (The page the user gets directed to once they fill up the login form). Any modern web framework as XSRF protection (Cross Site Request Forgery protection) and will disallow this approach for security reasons.
See if the auth this site uses has any kind of OAUTH, Single Sign On (SSO) or similar type of authentication integration that you can do. (Similar to an API, so you may have already explored this option)
Proxy all requests to this site through your server. You will have to rewrite the entire HTML so that all images, CSS, stylesheets, and all other assets are also routed through the proxy or else the URLs are rewritten in the HTML to not be relative. You might hit various walls if a site wasn't designed for this use case. From things like the site using relative URL's for assets that you aren't proxying, the site referencing non-relative URL's causing cross-domain errors, etc. Note its really hard to re-write every single last assets reference, its not only the HTML you're worried about, Javascript can have URL's in it too, and CSS can as well.
You could write a bookmarklet or a browser extension that logs the user into the site.
Have everyone install Lastpass
Have everyone install the TamperMonkey browser extension (and others like it for other browser), and write a small User Script to run custom javascript automatically to log the user in on that site
Scrape that site for the info you need and serve it on your own site.
OK I'm out of ideas. :)
ASP.NET MVC Web application where I am wanting to hold on some sensitive information (an account number) while the user navigates from page to page. I currently am using FormsAuthentication and storing it in a custom IPrinciple. I've encrypted the session cookie and set it to be HttpOnly (can't be accessed via client-script only). This seems like a good and secure solution to me.
However, I've been told we probably want zero sensitive information in a cookie for any reason. So an alternative I'm considering is storing the sensitive information in HttpContext.Current.Items. This would require the user to re-log in for each request but that's ok in this case. They should never come to the site directly, but through links from other sites (which posts authentication information, so the user never manually logs in).
Is there any reason not to use HttpContext.Current for this purpose?
I have a Rails application that make several user-specific calls to a third-party API. They interact with a lot of data in the course of filling out a survey, and their progress is stored in HTML5 localStorage until they reach the end of the survey and the data is saved in a local database & localStorage cleared.
The API calls require a token tacked onto the end as an "auth=" parameter. Right now, I have the user log into my app with their username and password to that service, POST those credentials to the "sessions" call of that API, and get a token back in JSON. I store that token in a variable in the controller, and use it to make the successive API calls and present the user's data in my app, etc. etc.
I've learned quite a bit about Rails, but next to nothing about sessions or authentication. Generally speaking, is there anything more I need to do for this to be a secure scenario? I feel like I'm missing something.
Assuming the user's username / password combination for the 3rd party service doesn't hit your servers, seems OK to me.
If your servers see the user's credentials, that's not particularly cool. Instead use OAuth to get 3rd party sign in, and use the token to make requests on behalf of the user. You can usually keep the whole session on the client if you want to avoid saving users to the database.
Storing progress in localstorage sounds fine btw. To preserve values you can have the pages of the form be tabs (so hide the previous form, not a new page) and use:
autocomplete="on"
to signify that the values should be restored to what they were. Try that before writing code to save things to localstorage.
Assuming I have internet browsers like mozilla and iexplorer, so, I used mozilla and I have already logon to a website using my account username and password logged in, well idhttp can post(submit form, automated click) to the already opened account(without opening the web browser)? OR I will have to used again my username and password to post a submit?
I dont need a code, just asking for answer YES or NO, and if NO! what control in the INDY should I use in my approaced?
Sample: I want to automate a submit button for a click(my account is already logged-in)!
thanks
There is no simple YES/NO answer to your question. It depends on how authentication is handled by the web site/server.
By default, http is STATELESS: each call into the server knows nothing about the previous call. In that case, you will have to authenticate EACH TIME you hit the server.
But most modern sites implement some kind of authentication persistence: either by maintaining user session information on the server, or, as Arnaud Bouchez mentioned, sending back a cookie that keeps track of your authentication.
I once wrote a custom web application that sent back an encrypted authentication token with the first response, and it was the client's (it was a custom Windows client with an embedded socket implemented using idhttp, not a browser client) responsibility to send back that token for each subsequent request.
So, your answer is: Let the server handle it - you generally don't have much choice.
I suspect the authentication will be local to the browser, i.e. validated via a browser-specific cookie.
From the Delphi code, you would need to retrieve the cookie (it may be possible, e.g. from a SQLite3 file with FireFox, or as plain text in user profile with IE), then use Indy to query the web site, including the cookie content within the request headers.
But it will highly depend on how the authentication is done. For instance, does it use HTTP or HTTPS protocol? How is implemented the server side?
How about creating a custom browser with a function to auto submit after you login to the site?
I ever make a custom browser with an auto form submit function using TChromium and TBrowser.
It's easy. You just need to know how to control dom using javascript and also manipulating the page source.
Sorry for the simple answer
I am trying to write a script that will provide XML data to a third party client. I wish to require that all clients are authenticated in order to make use of the system.
Rather than using a bespoke authentication system, which would be overkill, I want client applications to just pass in their credentials via the url, such as http://myusername:mypassword#mysite.com/. This is not unlike how it is done in FTP.
I think this is possible using .htaccess, but when I do try it, I still get a dialog prompt asking me to login or confirm the credentials that I will be using to login. Is there a way that I can suppress this in the .htaccess or an alternative way of authenticating on the server?
This is probably a security fix of the Internet Explorer, which was introduced by Microsoft some years ago. If you retry it with Firefox, it should work.
If you want to allow the Internet Explorer to login via the given username and password, check out this Microsoft article on the theme, especially the workaround section. And btw, the url is supposed to be http://username:password#example.com (note the double-slash).
Also, please make sure your .htaccess is correct by entering your login-information in the credentials popup - you should be able to login anyways.