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
Related
I am working on Asp.Net MVC 5. When i click a link (placed in another website) I navigate to UserDetails.cshtml page. Basically that 3rd party site is passing the UserName & Password to my site & using that I authorize & display further user info.
It's fine but the Url is looking like this
localhost:8080//Admin/UserDetails/UserName/PWD.
I don't want to show the UserName & Password in URL i.e URL should look something like :
localhost:8080//Admin/UserDetails/
One possible solution could be rewrite the URL in IIS (http://www.hanselman.com/blog/ASPNETMVCAndTheNewIIS7RewriteModule.aspx)
But I believe there is an easier way to handle this by using the routing mechanism of MVC.
Please help me to figure out the same.
EDIT :
As many of you are confused why I am not doing a Form Post here, let me re-frame my question. I have no control over the third party application, so I cant request them to do a form Post to my MVC application. Again the 3rd party application is a Oracle Reporting application (OBI), so doing a POST from that application might not be feasible too...
Let me reverse engineer your requirements from your question:
I want to have an URI that when invoked will give access to a secured section of my website. This URI must be clicked by visitors of a third-party site, whom I give that URI to. I want to hide the credentials from the URI.
You cannot do this, the requirements are conflicting. You cannot hand out URIs that will authenticate anyone who fires a request to that URI.
You could do something with a token (like http://your-site/auth/$token), but then still, anyone with access to that URI can use it to authenticate themselves, or simply put it up on their own website.
If you have data you want to expose to a third-party site, let that site perform an HTTP request (with tokens, usernames, headers or whatever you want to use to authenticate) in the background to your site, and display the response in their site. Then the visitor won't see that traffic, can't share the URI and all will be secure.
No. No. NO. Like seriously, NO. Any sensitive information should be sent via a post body over a secure connection (HTTPS). You can't "hide" information in a GET request, because it's all part of the URI, or the location of a particular resource. If you remove a portion, it's an entirely different location.
UPDATE
I find it extremely hard to believe that any third-party application that needs to authenticate via HTTP and isn't designed by a chimp with a typewriter, wouldn't support a secure method to do so, especially if it's an Oracle application. I'm not familiar with this particular app, but, and no offense meant here, but I would more easily believe that you've missed something in the documentation or simply haven't found the right way to do it yet before I'd believe you have to send clear-text credentials over GET.
Regardless, as I said previously, there's no way to hide information in a GET request. All data in a GET is part of the URL, and therefore is plainly visible in the browser location bar or whatever. Unfortunately, I have no advice for you other than to look closer at the documentation, even reach out to Oracle if you have to. Whether by post or something like OAuth, there almost has to be another way.
Question #1:
Is setAuthCookie any less safe than FormsAuthentication.Encrypt(ticketVariable)?
I mean if anyone tries to modify the cookie created by setAuthCookie, by modifying the username, I suppose that'll violate the authentication on subsequent calls?
Question #2:
for those using iphones and tablets to access the site, I suppose FormsAuthentication will fail? Given that I don't want to use cookieless option, is there another approach to make the site secure on both smart phones web browsers and ummm none-smartphone web browsers?
cheers
SetAuthCookie basically creates a new FormsAuthenticationTicket with the supplied username & persistence options, serializes it, FormsAuthentication.Encrypt()'s it, and sets it in the Response.Cookies collection. SetAuthCookie and GetAuthCookie both call FormsAuthentication.Encrypt indirectly.
On subsequent requests, the FormsAuthentiationModule handles the AuthenticateRequest event. If it sees a cookie (it may have expired), it attempts to decrypt it's value with the machineKey (it may have been tampered with) and deserialize it back into a FormsAuthenticationTicket (it may be corrupt). If none of that (bad stuff) happens, the ticket contains the username, issue date, expiration info, etc.. If the ticket hasn't expired, an IIdentity and IPrincipal are created and assigned to HttpContext.Current.User and Thread.CurrentThread.Principal. In .NET 4.5 and later (I think), this is Claims-based (ClaimsIdentity, ClaimsPrincipal). Prior to that, it was a (GenericPrincipal, FormsIdentity) I think.
Any tampering at all on the user side will cause the request to be treated as anonymous. It will fail to decrypt. The only things that would compromise this validation would be if the machineKey in web.config/machine.config somehow got into the hands of an attacker or if there was a bug in the framework code (search for Padding Oracle for a historical example of this).
Aside from that, the other thing to watch out for would be session hijacking. If someone steals your cookie on a public wifi for example, they can present it to the server and the server will behave as if it's you. This generally involves network traffic sniffing. For these reasons, best practice is to use SSL for your entire site and set the cookie to HTTP only and Secure (only presented over https connections) in web.config/system.web/authorization/forms. HTTP only means that it will not be available to client-side Javascript. HTTP Only and Secure effectively means HTTPS only. This will only work if you use SSL on your entire site.
FormsAuthentication will work fine on mobile web browsers. It simply requires the client to accept cookies. As far as I know, all mobile devices will allow this.
I have to implement a web site (MVC4/Single Page Application + knockout + Web.API) and I've been reading tons of articles and forums but I still can't figure out about some points in security/authentication and the way to go forward when securing the login page and the Web.API.
The site will run totally under SSL. Once the user logs on the first time, he/she will get an email with a link to confirm the register process. Password and a “salt” value will be stored encrypted in database, with no possibility to get password decrypted back. The API will be used just for this application.
I have some questions that I need to answer before to go any further:
Which method will be the best for my application in terms of security: Basic/ SimpleMembership? Any other possibilities?
The object Principal/IPrincipal is to be used just with Basic Authentication?
As far as I know, if I use SimpleMembership, because of the use of cookies, is this not breaking the RESTful paradigm? So if I build a REST Web.API, shouldn't I avoid to use SimpleMembership?
I was checking ThinkTecture.IdentityModel, with tokens. Is this a type of authentication like Basic, or Forms, or Auth, or it's something that can be added to the other authentication types?
Thank you.
Most likely this question will be closed as too localized. Even then, I will put in a few pointers. This is not an answer, but the comments section would be too small for this.
What method and how you authenticate is totally up to your subsystem. There is no one way that will work the best for everyone. A SPA is no different that any other application. You still will be giving access to certain resources based on authentication. That could be APIs, with a custom Authorization attribute, could be a header value, token based, who knows! Whatever you think is best.
I suggest you read more on this to understand how this works.
Use of cookies in no way states that it breaks REST. You will find ton of articles on this specific item itself. Cookies will be passed with your request, just the way you pass any specific information that the server needs in order for it to give you data. If sending cookies breaks REST, then sending parameters to your API should break REST too!
Now, a very common approach (and by no means the ONE AND ALL approach), is the use of a token based system for SPA. The reason though many, the easiest to explain would be that, your services (Web API or whatever) could be hosted separately and your client is working as CORS client. In which case, you authenticate in whatever form you choose, create a secure token and send it back to the client and every resource that needs an authenticated user, is checked against the token. The token will be sent as part of your header with every request. No token would result in a simple 401 (Unauthorized) or a invalid token could result in a 403 (Forbidden).
No one says an SPA needs to be all static HTML, with data binding, it could as well be your MVC site returning partials being loaded (something I have done in the past). As far as working with just HTML and JS (Durandal specifically), there are ways to secure even the client app. Ultimately, lock down the data from the server and route the client to the login screen the moment you receive a 401/403.
If your concern is more in the terms of XSS or request forging, there are ways to prevent that even with just HTML and JS (though not as easy as dropping anti-forgery token with MVC).
My two cents.
If you do "direct" authentication - meaning you can validate the passwords directly - you can use Basic Authentication.
I wrote about it here:
http://leastprivilege.com/2013/04/22/web-api-security-basic-authentication-with-thinktecture-identitymodel-authenticationhandler/
In addition you can consider using session tokens to get rid of the password on the client:
http://leastprivilege.com/2012/06/19/session-token-support-for-asp-net-web-api/
When trying to login in to Hotmail I get a Javascript Redirect. Is there a way to avoid it?
IdHTTP1.Get('http://www.hotmail.com');
Cookies must be allowed Your browser is currently set to block cookies. Your browser must allow cookies before you can use Windows
Live ID.
Cookies are small text files stored on your computer that tell Windows
Live ID sites and services when you're signed in. To learn how to
allow cookies, see online help in your web browser.
JavaScript required to sign in Windows Live ID requires JavaScript to sign in. This web browser either does not support JavaScript, or
scripts are being blocked.
Indy will not pass up a recognised user agent for you, you'd probably have to set that yourself. Also as it states you need JavaScript support, which Indy will not give you.
Your only real option is to automate something like IE, WebKit or Gecko or wrap some headless browser like PhantomJS.
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.