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
Related
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 a like/dislike buttons and I put them in an update panel to be able to update the counter without refresh the page, the problem that the user can click like/dislike button several times and the counter will be changes
I want to allow user to click the button once I think I may use cookie but I didn't used it before so if anyone can help me doing that I will be thankful
also if there is any other solution that may be better please let me know
Thanks in Advance
If you want to use cookies, you can look at this page (older version) or this page (newer version).
You haven't described what kind of website you are creating, but if you have a user registration/login mechanism, you could just save information that a specific user clicked the like button in your database.
If logging in is not acceptable, you can try to identify your users by their IP addresses, as Adam suggested. You can do this by using:
String remoteAddress = HttpContext.Current.Request.UserHostAddress;
or
String remoteAddress = HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"];
Either way I think it would be best to use cookies combined with another method, because you can then check the cookie first. If it exists on a user's computer, you know she/he has already voted. If the cookie is not there, you can query a database for the saved information about the user (identified by IP or login mechanism). This way you can make less queries to the database, which should be good for your application's performance :).
Instead of using cookies you can track via IP address.
I know IP addresses can change over time so you could use this with cookies but cookies can also be cleared so nothing will be 100%.
When a user clicks like or dislike, store their IP address with the record of the like.
Place code to stop another like or dislike counting if they already have done so.
Then on your update remove the like or dislike button and just show the count.
This is what I use for my application. I also have a Facebook app, in which I use their Facebook user Id which is much harder to fake.
Either way I think IP address is the best way to detect and stop someone from doing it twice.
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.
My bank's website has 2 login pages for online banking. On the first page, I enter my username. If I don't enter a valid username, I get an error message, and do not get to the 2nd page. The 2nd page displays a picture based on my user name, and has me enter my password. If I manually type a URL to a page inside the site after entering my username but before entering my password, I am redirected back to the first login page.
Is there a good way to implement this in ASP.NET with Forms Authentication? I only get 1 loginUrl in my web.config.
I am fairly certain my bank uses Java.
I do not find this a good idea, because this way any attacker know if the user name is the correct, then its need to know the password.
Second reason is that is more complicate and you need to be sure that you do not forget something on the way to login.
Third reason is that is not the common way to login, so people did not have use to it.
If you like to make the same, you need 2 pages, in the first you ask the user name, then you search on your local database if this is a valid user, then you keep this user name on a variable that you send on the second page that is the actual login. On the second page you have a common asp.net login module, but you have hide the user name, and at the same time you have set it with the value from the previous page. And then the rest is up to you.
Hey I know the bank on this one. Well provided it's the same bank there is another page that the user has to visit if they are on a computer thats never accessed the login before. Once the enter the user name they visit a question answer page where the question is a random one they picked when they first signed up or at least when they thought up this cockeyed login page. Then they visit the password page.
You can implement this yourself if you are using the built in AspNetSqlMembershipProvider provider you can customize the built in login control and override the OnLoggingIn method. You can then do what ever checks you need on that login and move it to another page. On the next page you can override other methods the same way like: OnAuthenticate, and OnLoggedIn while still using the built in control (but customized) if needed. Then you can set the login page in your web.config to your first login page. You can see MSDN for other methods as well.
Now as already pointed out this is not ideal because it's not typical and most users will not understand what is going on or think it's flaky (just like i do about the bank). Not to mention you will need to do additional checks similar to how that bank is doing it to make sure everything is legit coming from the client. So in the end I wouldnt recomend it, it's to much hassle for the end user mainly.
I'm thinking of creating a diagnostics page for an ASP.NET app, which would be mostly intended for admin use to get more information about the application for diagnosing problems.
Examples of the info the page might have :
System.Environment.MachineName (might be useful in web farm scenarios)
System.Environment.Version
Environment.UserName
database name
current user's session ID
Some of the info on this page might be sensitive from a security perspective.
If you've done this sort of page before, what sort of security did you put on access to this page ? .
EDIT :
I should add - occasionally it might be useful to see this page whilst logged in as a specific (i.e. real) end user. e.g. say a problem can only be reproduced when logged in as a particular user. Being able to see the diagnostics page for that user might be useful. e.g. knowing the current session ID might be helpful for debugging.
EDIT 2 :
I'm starting to think that this diagnostics page should in fact be two different pages. One to display stuff which is the same for all users (e.g. database name, CLR version), and another for stuff which can vary by session (e.g. browser info, session ID).
Then you could lock down security more for the first page.
Yes, I've added this sort of page before (and found it useful). The security was pretty simple: the page contained a password form. The server-side code checked this password against a configured value and, if correct, displayed the real content and set a value in the user's session to say that they've been authenticated as a developer, so that they're not prompted again next time.
I suppose there was also a little security by obscurity, since the URL of the page wasn't published anywhere.
I was also careful not to reveal anything really sensitive on the page. For example, it allowed viewing our application config values, but masked out anything with "password" in it - hey, if we really want to see the password we can open a remote desktop session to the server.
There's also a couple of other ways you could do this:
If your web application has user authentication, restrict access to this page by checking that the user is flagged as an administrator or belongs to some kind of admin role.
Use a simple if (Request.IsLocal) ... type check, though the downside of this is that you still have to connect to the server and browse the website locally - which might not always be possible. However, this does still have the benefit of being able to easily view key system settings.
Personally, I've used a combination of both methods where a local request always allows access, and non-local requests require an admin user - eg. if (!Request.IsLocal && !IsAdminUser()) throw new SecurityException().
Also, I'm in agreement with Evgeny - be careful not to reveal anything really sensitive on this page (such as application connection strings or passwords).
use forms authentication and setup a user or two with access to that page. that way you can change passwords and revoke access once the site is deployed.
It sounds like you want a robust solution for your error page. I would take a look at open source projects like Elmah (http://code.google.com/p/elmah/) for a good example of a robust error page which includes configurable security. To give you an idea, here is a post on configuring Elmah which takes you through setting up the security. The security I have tested allows me to use my domain credentials to login.