I've built an ASP.NET application that's using Forms Authentication. In our hosting account control panel, I set up an automated task that requests a web page once per week. When the page loads, a number of emails are sent out.
I'd just like to know if there's any way to determine in the code-behind if the request is coming from the local machine (as with Windows authentication). Using a separate web.config file in the page sub-directory with Windows authentication mode doesn't work.
The application will work fine either way. I'm requiring that a specific Guid value be present in the query string, so it's very unlikely that the task will be executed by mistake. I'd just like to learn something new while I'm working on this, and I'd like to see if I can add this little bit of extra verification.
Thanks very much for any advice.
Request.IsLocal
The IsLocal property returns true if
the IP address of the request
originator is 127.0.0.1 or if the IP
address of the request is the same as
the server's IP address.
Request.Url.IsLoopback
Related
I am trying to create an authentication system that works within the limitations of my organisation's network infrastructure both when inside the local network and outside.
When inside the local network I want people to be able to access this ASP.NET Web Forms application without having to log in using their Windows login.
Externally I want people to have to log in through a custom login form.
The reason is that Windows authentication does not work outside of our local network, due to the local infrastructure.
So, I created a password protected folder by disabling anonymous authentication just for that folder, and then on every page request I check if the user is flagged as being logged in (details on how I do this are unimportant) and if they aren't I redirect to a page that does an AJAX request to a web service located inside the password protected folder to see if they are logged in on the local network. If they aren't then it redirects to the custom login form page.
Now this all sounded like a good idea at the time but in practice it does something undesirable... When an external user attempts to access and the AJAX request is made, I get a browser username and password prompt which has to be cancelled to continue.
I appreciate that this type of authentication is part of HTTP and probably can't be bypassed, even using AJAX, but any ideas how I can get this working without the username/password prompt or an alternate way of checking whether local network or external access?
I know I could check the IP address but I understand this can be faked (although that would only cause an issue to the user attempting to do this).
I also know I could have a different entry point for internal or external but I wanted to avoid this.
I couldn't find a solution for exactly what I wanted to do, so I opted to check if the user was on the local network by checking their IP address.
Although this is sent via a HTTP header and can be faked, it will only result in the user being prompted for username and password via Windows authentication.
I am not very familiar with hacking techniques and safety vulnerabilities, but I am starting to worry a little bit about our site's security, which is built on ASP Classic, running IIS 7.5
We use ASP inline authentication. Inside the ASP file I have the username and password set up. I have restricted the access to a certain username to a specific IP address (the username used by employees) and the other usernames use a confirmation password received by SMS on the phone.
Is the IP based auth safe? I've heard of entering a certain IP address through certain ports and thus gaining access from that certain IP address.
Can the content of the ASP file get hacked and read?
When generating the SMS, the ASP script opens a link through XMLHTTP 'https://generate.sms-company-domain.com/?password=&acount=&message=Your confirmation password is '. Could somebody listen to the URL that are called and easily get the SMS password?
Can you think of any vulnerabilities of our log in methods?
Thanks!
your 3rd point is looks like problem if URL expose in that way any one can read password or information via some tools like fiddler.
for protect your site from hacking please make sure
1) you site used SQL injection technique
2) all important data submit via post method.
3) need to take care of Cross site scripting attack like when someone load page it save one encrypted value in cookie and in code read that cookie value so we can confirm that page is not calling from some other place.
Im currently in the process of exposing our internal CRM system to the web so our employees can use it outside out network. The data is being surfaced to our web application via asp.net WebAPI.
We have SSL setup on the website. But am thinking how else I can make sure the WebAPI is secure from malicious use. My ideas are:
Tracking what IP addresses are accessing the WebAPI and only allow addresses that we have validated are from employees. Problem with this having dynamic IP addresses we might be constantly updating a data store of valid IP addresses.
The user has to login to the system. So every request to the webapi will send across their login details which will be validated before the webapi will process any request.
Pass the device ID of the device using the webAPI and validate (pretty much the same as IP Address tracking in idea 1)
Having a unique clientside generated access token which much match up at the server side.
Has anybody got any advice on my security ideas I outlined? Is it to little or is it overkill?
Just want to make sure the data cannot be hacked, because my butt would be on the line if it did.
Thanks in advance
I would actually choose a totally different solution - updating valid dynamic IP's will be hell.
I would:
Create a new Project using the "Intranet Application" instead of using "Internet Application"
Host the application on your local office network
Set up VPN to your Office for your colleagues
Would this solution be possible for you?
I'm using IIS 7.0 on WS2008.
I've implemented a simple login page that redirects to another simple page showing the Request.ServerVariables key/values.
I'm using the built-in SQL membership provider.
The website is on a DEV machine and there are no users on it.
When I login at the same time with 2 different users from 2 different locations (2 different public addresses) then one of the Request.ServerVariables page is the same as the other.
That includes the client IP address which is then completely wrong.
The authentication as well as the other cookies are wrong as well.
I checked the IIS log and it shows the correct client address as well as the correct login name.
If I then reload the wrong page I get the correct data.
Is there some concurrency issue in ASP.NET? I disabled the session and caching but I still get the same behaviour.
Cheers.
We had exactly the same issue when we accidentally cached too heavily on the IIS. The website simply returned whatever it had returned before.
Take a look at the site settings and see if you have any settings in the "Output Caching" of your website.
I have my website, and it records the number of visitors, IP and time of access...
I want to identify each visitor... I think that this was possible recording IP Address... but when the IP is dynamic, my system fails. So I think that I can solve it recording MAC address... is possible? What language should use? PHP, ASP, Javascript?
Thanks
Edit: What I can use to identify each user without having login information (username & pwd).
The MAC address, by TCP/IP standards, is never communicated outside of the local-area network to which it pertains — routers beyond that LAN don't even get the information you're trying to record.
There are many other ways to try and identify unique visitors, including matching the user-agent's details in addition to the IP, serving cookies as part of your response, etc… it is, after all, a core functionality in the field of "web analytics".
MAC addresses are simply not part of the gamut of techniques that it makes sense to utilize for it!
It is only possible if you use a technique where you install a "native" app on the client machine. For example, an activeX component, java applet or a client application. Then that application, once installed can get the MAC and then call to your web server with the MAC as an argument. In other words, you have to build your own front end "browser" to handle logging in. Then once the user is logged in, you can launch the app in the default browser.
It would be nice if future browsers allowed users to give permission to specific sites to access the MAC. Then if a site had a button that said "Register this device" the web application could do so without needing an additional native app installed (after all, the browser IS a native app).
Can't you just have them store a cookie, so that when they come back they can be uniquely identified? No username/password requirement.
http://en.wikipedia.org/wiki/HTTP_cookie
Sorry but sending MAC address isn't part of the HTTP. However, you can use cookie to identify different users. Any backend language will do (add cookie in the server side). You can set the cookie in the client side using JavaScript too.