On some websites, when you want to login, you need to enter a captcha as well. If I want to provide support for an user to enter a captcha into my application ( which will then log into the website ), how would I do this?
My problem is that the link to the captcha image is like this: example.com/captcha , and it serves a different image each time it's accesed.
My approach is like this:
request page
download image
show image to user
user inputs login information
application logs in
The thing is, if you download the image in order to show it to the user, you're actually receiving a different image than the one generated when the page was loaded, right? How can I get to the image that was generated when the page was loaded, so that when I show it to the user, it's the correct one?
The question is language agnostic.
I think your problem is about sessions, the session your app downloading the image and the session your app submiting the login form may not be the same session, then your captcha will never be correct, you should maitain the session between requests, normally is some cookie set by the website.
By design, most captcha will always give you a different image. No way to work around that fact.
The first thing to do, is to open up fiddler. That way you can see what the browser is doing so that it can autenticate & remain autenticated.
It usually comes down to a cookie being sent. So what you need to do is to hold the cookie on your client app, and have all the requests sent with that cookie. Different platforms provide features to do so, but I'm sure a quick search will show you how.
Remember to pay attention to all being exchanged in fiddler, you need to make sure your apps triggers the same. Besides cookies, pay attention to any hidden field a js might set on the form.
It sounds like you're trying to invent a captcha solution yourself. Have you considered using reCAPTCHA? It's free.
Can you be a bit more specific about your situation? From what you've said, I'm assuming the following:
You have a "client GUI app" that logs in to a third-party site. Is this a web-app, or a desktop/standalone application? In what language is it written?
Your app contacts the third party site and downloads the Captcha image. This image is then shown to the user.
The user enters the captcha phrase and submits it to your app. Your app then submits this phrase to the site for validation. This is where sessions come in. Assuming the remote site uses cookie-based session tracking, you will need to send the same cookie to the third-party server with this submission as you do when the image was downloaded (in the step above). This allows the server to match your submission to the correct image it sent. Precisely how you do this depends on what language you've written your app in and the precise structure of it all. Without more information, a more specific solution is impossible.
The image that's generated is also the image served to the user. Your 'main' html page doesn't/shouldn't generate the image, it only embeds it using the image tag.
You could pass a token of some kind with the captcha image, perhaps appended to the filename such as captcha-0ad719bef61bc6a0.jpg and the appended data could link into a temporary table in a database server side that has the correct answer. This would allow you to check things were ok without passing both the image and answer across to your application.
I'm not sure if I entirely understand this question, but wouldn't you simply store the captcha locally after requesting it from the server, and then embed the local image from the client application, while storing any necessary session captcha data that will allow the captcha to be validated on post, assuming the user input is correct?
If the problem is that the captcha changes everytime you request it, just request it only once.
Can you offer any more clarification if this wouldn't apply to you?
It depends from capcha to another captcha. Maybe you need to use sessions or cookies or some captcha image filename. Show the page with that captcha.
Related
Today, our B2B web application times out user sessions after 6 hours of inactivity. If a user's session times out, the user is redirected to the login page, and then redirected back to the original destination after login (via a "returnURL" querystring parameter sent to the login page).
This works great for regular HTTP GET requests. But what if a user is in the middle of a long data-entry operation and then goes home for the night? If the user tries to submit the form the next morning, their changes are lost.
Instead, I'd like to enable a similar workflow for forms like we currently have for GET requests: the user clicks "save", the user is forced to re-authenticate, and (if login succeeds) then the form would be submitted. Another alternative would be to force a re-login, but instead of submitting the form, simply drop the user on the original page so that the user could try again to save changes.
All the data we need to submit is on the client-- it's not like we're storing data in the session that would have been lost.
Is there an accepted pattern to handle this case? Should I use a window.open popup window and close it after successful login? Use a jquery dialog overlaid on the page? Something else?
I know that login UI is often treated specially by web apps to reduce cross-site scripting risk and for other security-related reasons, so wasn't sure if there was a well-known best practice for this use-case.
One way to handle this would be to periodically save drafts of the user's work, like StackOverflow does. For cost reasons that's not practical in our case-- for now we simply want to make saving-changes workflows resilient to session expiration.
We're using ASP.NET MVC on the back-end if it matters, and jQuery on the front end, but my question is really more about security and programming best practices that I'd expect to be platform-neutral.
It would depend on the amount of data being collected, but a possible solution could be to save the page state to the browser's local storage using either "localStorage" or "sessionStorage". "localStorage" and "sessionStorage" are properties of the web browser that are exposed in Javascript and are supported in most modern browsers (Chrome, Safari, Firefox, IE 9+). "localStorage" holds data indefinitely while "sessionStorage" holds data until the browser or current tab is closed.
It may be possible to store everything needed about the page, redirect the user to log in, and then reload the page using the stored data.
Before redirecting to login:
if (window.sessionStorage) {
window.sessionStorage.setItem("firstName", $("#firstNameField").text());
window.sessionStorage.setItem("lastName", $("#lastNameField").text());
}
After retunring from login:
if (window.sessionStorage) {
$("#firstName").text(sessionStorage.getItem("firstName"));
$("#lastName").text(sessionStorage.getItem("lastName"));
}
I've been asked if there's any way I can link to a resource on a site without making that resource visible via an external link.
The client wants a price list only available via a link on a page on the site itself. Is this possible?
Well, the link will be visible, but if it's a link to something nobody else is authorized to see then only authorized users would be able to see it.
For example, you might link to something which requires authentication. When anybody clicks on that link, they're prompted for that authentication and are validated before the content is returned to them. If only this particular client is authorized, nobody else would see the content.
You might even link to a URI which is only physically accessible by that particular client. For example, a file on that client's machine. Something like this, for example:
click here
Only that client has that file, so the link would fail for anybody else.
Either way, the link isn't the issue. The access to the resource being linked to is the issue. As long as that access is protected, nobody else can see it.
Of course, as an added UX concern you might also conditionally only display the link if that same authorization is available. You'd still want to protect the resource itself, since otherwise it would just be "security through obscurity", but you should also really only show the link if the user is expected to be able to access it.
I have an ASP.net web page that should only be accessible should the user enter a valid Pin number on the welcome page. They shouldn't be able to simply access the page by typing in the URL in their browser, for example.
Flow: User visits web page. User enters their Pin on the welcome page.
If Pin is valid, user is redirected to the page in question.
If Pin is invalid, show an error message stating that the Pin is invalid.
Okay, right now I have it set up so that they are redirected to the page if the Pin they enter is correct. Problem is, this doesn't negate them from being able to enter the URL in their browser or otherwise access the page. Of course, I could make the URL long and obfuscated, but this doesn't seem to me secure.
I have a lot of ideas of how to make the page secure. The best example, is creating an obfuscated unique URL based off of their Pin, that redirects to the page in question, but I'm not sure how to accomplish this within the ASP.net realm. It seems like there are methods, properties, or just in general coding techniques that should be built in to .net which handle this, since it is so common. I just don't know about them, personally.
Also, I would like to make the connection to this page secure, perhaps using Https or some other security method. Maybe this is best left to another question.
I dont want to sound harsh here but what you want to accomplish, should be based on proper security. I would start with these tutorials and make my way from there http://www.asp.net/web-forms/tutorials/security
In short you could contain and restrict the user by logging onto the site, database security etc. This would give you further control and allow future updates and or add additional security methods if required.
Hope this helps
I have built an ASP.Net MVC site using Forms Authentication for a client.
Recently, they have requested that an authenticated user be restricted to a single browser session. That is, if the user raises a new browser instance, or opens a new tab on the original browser window, that he/she be logged out of the original. They insist on the added security.
Does anyone know how I might approach this? Thanks in advance.
Personally, I would push back and ask exactly what security this is bringing. Maintaining state like this counter to web architecture and is only going to bring you and your users grief.
Here is what I would do if presented with this problem:
Store the username of the user in your database (i.e. LoggedOn table).
When a user logs on, check to see if their username is already present in the LoggedOn table.
If the user isn't already logged on, insert a row into the table with the username and the current time; otherwise present the user with a message informing them that they can only log into the system from one device at a time.
Include logic to expire and delete the rows in the table if a user's session expires or if the user logs out.
First a disclaimer: I'm no expert in web programming.
Perhaps you might try a system where every user interaction requires the submission of a random value that's been generated for that page (much like what's used for CSRF protection.) That key could be kept under the user's session information on the server, and if a page is ever requested without the correct key as a URL parameter, the session is invalidated. The URL from one browser won't work in another, either, since once a URL is gone to, the user's session key has changed. The only way for a user to transfer a session between tabs would be to copy the URL of an unclicked link and paste it in a new tab's address bar. Switching browsers would be even more complex assuming that ASP.Net uses a session cookie: the user would have to transfer the cookie from one browser to another. Going back would also fail, as all the links on the previous page, and the URL for the page, would carry an incorrect session key.
Also, for reference, I believe the US Gov't TreasuryDirect site works in the way you've described, though I've never looked at how they manage it.
Thanks, people for the suggestions. Each had strong merits, however I had to take a hybrid approach. I found an incredibly simple suggestion from this post.
I implemented table of active users as Karl suggested as well. This will give the client the ability of deactivating the user on demand.
Thanks again.
Think of it as one active view at a time instead of one browser or tab. Or convince the customer to view it this way.
You can always issue a unique cookie for the browser session (ASP.NET Session) and allow communication to the latest cookie issued effectively making only one session active at a time, and therefore rendering other open sessions (browsers, tabs, etc) useless with the app by disallowing them communication any longer or serving up an error page for them. To do so you have to recognize who the user is and authenticate them against your app. This is half the puzzle and will force the user down to use your app in only a single browser at a time on their machine.
The other part of the problem is to pare down the windows and tabs that are part of the same browsing session of that browser, to allow only one view to be active at a time. To do so you can issue a unique sequential ID to the viewstate of each page for postback to the server to uniquely identify that page apart from other pages sharing the same session state (whether that page be in a browser tab, a frame or new window, etc). Or a code of your choice that's traceable. You then know which page is posting back within the session and can disallow others or deactivate previous ones by, again, shutdown down communication in some manner or serving up an error page, etc.
A new browser instance or a new tab may or may not be part of the same browsing session depending on how the browser is configured. I believe, for example, IE provides a setting that allows the behaviour to be set of whether a tab opens in a new process or session or shares the session. You won't necessarily get expected consistency across browsers to rely on for this feature, therefore you need to take programming steps to reign it in, like those described above.
You can additional steps like disallowing the user to be connected from a different IP# at the same time.
My UI prototype requires me to show the sites login info all the time. Either I should show the usual username and password textbox or "you are logged in as". The last bit don't have to be secure, as it's only info to the user, nothing I will use server side. But the first part should send secure to the server.
It seems that I would have to use https for all pages on the site then. I would like to only use ssl for the things that are required to be secure.
One way is putting the login information into a https://../login.aspx and show it on my mainpage as an IFrame.
One disadvantage I can see is that the user won't know that https is being used, unless they read the IFrame src in the source code.
What do you think?
Are you using the built-in asp.net login controls or do you just use two textbox controls?
You could use your own form tag (not runat="server") with the action attribute set to "https://..." and just use two html input tags and a button to log on.
Again this wouldn't show the user that there credentials are secure when logging in.
Because of some recently discovered SSL attacks, it is always preferable to also put the logon form on a https:// page. Otherwise a hacked can intercept the http stream and change your form action from "https://..." to "http://..." and then sniff the credentials.
Another option would be to take advantage of the PostBackUrl property of the Button control.
You would need to create your own login LayoutTemplate to take advantage of this though. You would then be able to add the secure scheme to the current page URL, and set the PostBackUrl property of the submit button to that.
This would have a similar issues to your iFrame solution (the user wouldn't see the padlock symbols), however you would have the advantage that you wouldn't be using iFrames.
Another issue using an iFrame is the affects that they can have on the page:
They are a separate request, but can cause a block on the JavaScript PageLoad event firing.
The login form would only postback within the iFrame, so you'd need to refresh the parent page when the user is successfully logged in to remove it.
Additionally to that, errors would be returned in the iFrame, probably not leaving you much space for displaying the form as well, etc.
You've hit the major problems. You want the login, which needs to be on every page to use SSL, but you don't want the entire page to be SSL.
This is more of a business decision at this point than anything else. Would you rather your customers feel more secure about visiting your site, or do you want the login information present on every screen?
If you need to have both, you may need to also look at making your entire site SSL.