I am writing an app that will be used for a kiosk. The app will be asp.net, I will only want the app accessible from certain computers, using chrome.
I don't think limiting by up address would work since a few of the computers will be taken to conventions and used there.
I was thinking something with a custom certificate but would like advice.
I think the better way is to give login or/and password/special key to allow them to login through an identification page. After that, you put cookie into their chrome.
Finally, like all websites.
Related
I often have a need to secure a single page (i.e. Reports) on a public facing app so that only authorized users may access the page. In the past, this mean setting up a custom login form or using the ASP.NET membership provider or something else far too complex to serve the purpose. Is there an easier (safe) way to secure a single page in this fashion?
Some things I've considered:
Client certificates (initial setup is a pain)
A single master password (works in a pinch, but feels dirty)
Restrict access by host address (cumbersome when the need arises to allow external users access to the page). Also, need to support access via proxy (X-Forwarded-For) which can be faked by technical users)
Are there other options? Recommendations?
You can do it in your web.config file something like what is suggested here. As far as authentication is concerned the easiest way is to use windows authentication.
A login system is your best option. If you don't want to go through the trouble of setting up and managing a login system yourself, consider using OpenAuth.
You can achieve functionality pretty easily using DotNetOpenAuth. Users can then log in with their Google, Yahoo, StackOverflow, etc. accounts, and you get a token that you can store to limit access with.
I'm just curious if you can bypass the login into a asp.net website, which to let yall know, I have no control of using a unique url?
I have login credentials to the site, and tried using those to do this but to no avail.
So is this possible? Only thing I could think of was
http://username:password.awesomesauce.com/login/login.aspx
FYI I can log in fine, I just need this to login to the site via a 3rd party app. It is a major pain to login everytime with the app and sometimes many of the functions fail because its screwy with keeping an authenticated login
No, this is not normally possible.
This would be a very specific custom case - there is no standard for this as all logins are different, and authentication methods with databases etc. are all different.
FTP can work like this, but that is because the authentication is part of the protocol whereas in a web form it is not.
I used a firefox add on called Live HTTP Headers 0.17 to follow the url actions as it logins into the site. After turning on the capture option I logged in and it gave me this
Then I took the contents from the Content-Length catagory and appended it to the url like so
https://www.TROLLFACE.com/login/login.aspx?__LASTFOCUS=&__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwUJMTI2OTI3NTE1D2QWAmYPZBYCAgMPZBYMAiAPDxYCHgdWaXNpYmxlaGRkAiEPDxYCHwBoZGQCJg8WAh4LXyFJdGVtQ291bnQCGhYCAhkPZBYCAgEPFgIeBXN0eWxlBQtib3JkZXI6MHB4O2QCKA8WAh8AaGQCKg8PFgIeC05hdmlnYXRlVXJsBRZqYXZhc2NyaXB0Om9wZW5DaGF0KCk7ZGQCOQ8PFgIeBFRleHQFKUNvcHlyaWdodCAmY29weTsgMjAxMiBCIE8gWCBQYXJ0bmVycywgTExDZGQYAQUeX19Db250cm9sc1JlcXVpcmVQb3N0QmFja0tleV9fFgEFGGN0bDAwJGJ0bkNoZWNrSW52ZW50b3J5MdYH4EkMQWCgv%2FEOSMLJPNZ21rMa&ctl00%24cphMain%24txtUsername=USERNAME-GOES-HERE&ctl00%24cphMain%24txtPassword=PASSWORD-GOES-HERE8&ctl00%24cphMain%24btnLogin=Log+In
Please note the USERNAME-GOES-HERE and the PASSWORD-GOES-HERE
So far it works every single time, effectively skipping the login.
I have written a custom http module which I successfully deployed to sharepoint. The purpose behind this module was to track if the users to the sharepoint site had accepted an EULA (represented as a cookie in the request context) and then simply redirect them to another website (running independantly) to accept our EULA etc. The problem that I am facing at the moment, is that while users with their web-browsers using the site are fine, everything works as it should, but the trouble occurs with things like the SPFarms serch failing etc when trying to index the site. My quesiton is basically, how/what should I be filtering to ensure that my module only executes my logic for a request coming from a webbrowser and how to detect any of sharepoints crawlers etc such as the search service etc? I realize i can hardcode it to check for the username that the service is running on and check the filepath extensions and filter on that, but that seems like horrible design. please advise if you know of a better way to do this please
Try filtering based on the User-Agent string, in Request.UserAgent -- just don't rely on User-Agent for security purposes, since it can be faked.
Suppose I have a valid (i.e. signed by one of the commonly trusted authorities) cryptographic certificate on my server. I could obviously use it to establish https sessions and deliver the contents with confidentiality (only the endpoints can read them), authentication (both endpoints know who they're talking to) and reliability (the message can't be tampered).
Now suppose that I actually don't care about the first two but, instead, I just the need the last one. For example, let's say I have a static resource that I would like to sign (a-la PGP) so that I can give it to other untrusted hosts: if my certificate is public and the resource has been signed with it, any client should be able to verify that the resource has not been tampered (e.g. by the untrusted host).
The question now is: is there a standard way to statically sign a web page? (I obviously mean something builtin in all browsers) I'm aware of someone (Unhosted) who's trying to accomplish something like this by implementing much of the logic via Javascript but still I'm wondering if a more standard way exists.
I'm not aware of any such standard implementation builtin in a browser.
Even in the mail area where such behavior is "standard" for long time (S/MIME), we find issues every other day with different clients, relays and servers.
For a download you may revert to sending a PKCS#7 container and associate a tool that unpacks and verifies. At least plugins and helper applications are availabel everywhere.
I'm also not aware of any standard implementation like that within a browser. But, to back up a bit... some things to consider:
For executable content (like downloaded EXE files, ActiveX controls, Windows Installer, etc.), a common / standard solution is Microsoft Authenticode. See http://www.tech-pro.net/code-signing-for-developers.html. Similar solutions for Java, Adobe, etc. The CA you buy the cert from will verify your identity. When you sign an EXE file with a cert from a trusted CA, Internet Explorer will display the signer information / less scary warning message. Same goes for UAC elevation prompts in Windows Vista/7. You're probably familiar with this?
But for the static content situation, the standard solution is SSL. May I ask why SSL isn't an acceptable solution in your application?
The problem I see is that there's no way for the user to verify the identity of the web page from the web browser, other than clicking the SSL "lock" icon in the browser to view the certificate. The new SSL EV certificates should verify that you control the domain in question, and that you are who you say you are (i.e. not be able to get a "PayPal" certificate for www.paypal.com.hacker.cz).
It sounds from your question that you're looking for an "Authenticode for web pages" sort of thing: a certificate with a subject not tied to a domain name and where the web page could go anywhere. Unfortunately, I'm not aware of any such thing for standard HTML files. I believe you can sign things like Adobe AIR applications, which can be based on HTML / Javascript / etc., although I'm not familiar with that platform. It does place the web page outside of the user's normal web browser, of course.
If I am on a website#1, and I enter my username/pwd for website#2 on a login page that is on website#1, and website#1, behind the scenes, makes a httpwebrequest to website#2 and posts to the login page. If I then navigate to website#2, should I be logged in?
website#2 uses formsauthentication and I call a httpHandler that is on website#2 and pass it the username/password via the querystring.
Should this work?
What you're trying to do is called Single Signon. The way you're doing it, posting values from one site to another, probably won't work because you're using the same technique a hacker might use to trick user into sharing their login information. It's called a cross-site request forgery attack. IIS is configured not to allow that.
Generally, you need a central authentication system that both sites use to share login information. This can be done in several ways, including a shared database-based login system. Google "asp.net single sign on" for more ideas.
Do site #1 and #2 want their users to have single sign on?
If so, read up on single sign on. It's a bigger project than can be addressed here. There is a good book on it though from Wrox :
http://www.amazon.com/Professional-ASP-NET-Security-Membership-Management/dp/0764596985/ref=cm_lmf_tit_10
Or are we imagining something sinister?
If we are imagining something sinister, then evil site #1 would collect the credentials, then automate a browser on the server side to start checking to see if site #2 uses the same password and user combination. Then the server would have an authenticated session. This wouldn't give the user who accessed site #1 an auth cookie, the HttpWebRequest object on the server would get the auth cookie. Site #2 couldn't really do anything to prevent this because a browser request from one computer looks much alike a browser request from another. A well crafted attack would spoof all elements of the browser's request so that it looks like it came from a browser instead of a primitative HttpWebRequest object, which may not even set the user-agent.
Site #2 should stop using passwords and user Id or use 2 factor ID if they are concerned abut this, or do something that requires javascript for logon because spoofing a browser that is executing javascript is harder than spoofing a browser that just sends and receives http requests and responses.
There are too many security issues trying to auto-authenticate between sites. There needs to be a central security provider that both sites belong to so that hand off is completed securely.
We use CA's Siteminder for cross site authentication. Effectively, web 1 creates a unique session id on the siteminder server and passes any credentials and info to it. Siteminder invokes web2 and passes the information by means of session variables. Web 2 retrieves the data from the session and uses it. There's much more going on there but that's the just of it.
To do something like this, I would strongly consider using an out of the box solution as generally coding up custom security generally falls short.
While this can be done on some cases, in the form of an HTTP request with POST parameters, you will not be authenticated once you browse to site #2.
This is because, generally, these sites store a cookie on your end and these are domain-based, which means that even if you grabbed that and stored it yourself from site #1, the cookie name would not match site #2.
Additionally, site #2 may not be easy to authenticate against and this is usually a security concern that developers are aware of. This can be considered an attempt of XSS as well.
In case you're simply doing this for yourself, I'd recommend LastPass and save most of your info in it.
Please reconsider your goals and how to achieve them, this is not the way.
Edit: Link text.
This could work, depending on the security measures in place on website #2. For a secure website, this would fail.
I would recommend against this purely on the basis of good security and good coding/design practices.
If you are unclear what security measures stop this, you should probably educate yourself so you can prevent the same issues on your own site. See http://www.owasp.org/index.php/Top_10_2007
Since both your sites are using FormsAuthentication you can easily configure both of them to share FormsAuthentication encryption schemes.
This will allow you to do Cross Application Authentication automatically :)