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.
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.
Scenario:
I have a ASP.Net / Silverlight website with webservices for supporting the Silverlight apps with data. The website uses forms authentication, and thus the webservices can also authenticate requests.
Now I would like to pull some data from this system to a Android application. I could implement code for running the forms login, and storing the authentication cookie, but it would actually be much simpler to send the username and password in the webservice url and authenticate each call. I don't really see a big problem with this as the communication is SSL encrypted, but I'm open to be conviced otherwise ;)
What do you think ? Bad idea / not so bad idea ?
Conclusion:
After reviewing the answers the only really valid argument against name / pass in the url request string is that it's stored in the server log files. Granted it's my server and if that server is hacked the the data it stores will also be hacked, but I still don't like passwords showing up in logs. (Thats why they are stored salted and encrypted)
Solution:
I will post the username and passord with the request. Minimal extra work, and more secure.
See Are querystring parameters secure in HTTPS (HTTP + SSL)?
Everything will be encrypted, but the URLs, along with the query string (and thus the passwords) will show up in the server log files.
Bad Idea: The contents of your post are encrypted and though the URL parameters may be encrypted as well, they could still be visible to third-party trackers, server logs or some other monitoring software that can directly sniff your traffic. It is just not a good idea to open up a potential security hole in this way.
Users do tend to copy-and-paste URLs straight from their address bar into emails, blogs, etc., and save them in bookmarks, and so on.
And things like plugins, or even other software that reads, for example, window properties (alternate shells, theme managers, accessibility software) could end up with the info. And they might, for example, crash and automatically send crashdumps back to their developers.
And worms far less sophisticated than keloggers - like things that take screendumps - can get passwords this way. Sometimes even security software, for example if deployed in a corporate network.
And if the user has a local proxy, then they might be communicating in plaintext with the proxy which in turn is talking in SSL (not the way it's supposed to be done, but it happens).
And for these and more reasons, URLs with usernames and passwords, that used to be standard - such as ftp URLs with the username and password in the authority segment - are now typically forbidden by browsers.
https://www.rfc-editor.org/rfc/rfc3986#section-7.5
So, an emphatic NO, DO NOT DO THIS.
It is always good programing practice to not provide delicate info like username and password
in the URL. No matter how good a site is it can be compromised. So why provide with more info?
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
I would like to create web application with admin/checkout sections being secured. Assuming I have SSL set up for subdomain.mydomain.com I would like to make sure that all that top-secret stuff ;) like checkout pages and admin section is transferred securely. Would it be ok to structure my application as below?
subdomain.mydomain.com
adminSectionFolder
adminPage1.php
adminPage2.php
checkoutPagesFolder
checkoutPage1.php
checkoutPage2.php
checkoutPage3.php
homepage.php
loginPage.php
someOtherPage.php
someNonSecureFolder
nonSecurePage1.php
nonSecurePage2.php
nonSecurePage3.php
imagesFolder
image1.jpg
image2.jpg
image3.jpg
Users would access my web application via http as there is no need for SSL for homepage and similar. Checkout/admin pages would have to be accessed via https though (that I would ensure via .htaccess redirects). I would also like to have login form on every page of the site, including non-secure pages. Now my questions are:
if I have form on non-secure page e.g http://subdomain.mydomain.com/homepage.php and that form sends data to https://subdomain.mydomain.com/loginPage.php, is data being send encrypted as if it were sent from https://subdomain.mydomain.com/homepage.php? I do realize users will not see padlock, but browser still should encrypt it, is it right?
EDIT: my apologies.. above in bold I originally typed http but meant https, my bad
2.If on secure page loginPage.php (or any other accessed via https for that instance) I created session, session ID would be assigned, and in case of my web app. something like username of the logged in user. Would I be able to access these session variable from http://subdomain.mydomain.com/homepage.php to for example display greeting message? If session ID is stored in cookies then it would be trouble I assume, but could someone clarify how it should be done? It seems important to have username and password send over SSL.
3.Related to above question I think.. would it actually make any sense to have login secured via SSL so usenrame/password would be transferred securely, and then session ID being transferred with no SSL? I mean wouldnt it be the same really if someone caught username and password being transferred, or caught session ID? Please let me know if I make sense here cause it feels like I'm missing something important.
EDIT: I came up with idea but again please let me know if that would work. Having above, so assuming that sharing session between http and https is as secure as login in user via plain http (not https), I guess on all non secure pages, like homepage etc. I could check if user is already logged in, and if so from php redirect to https version of same page. So user fills in login form from homepage.php, over ssl details are send to backend so probably https://.../homepage.php. Trying to access http://.../someOtherPage.php script would always check if session is created and if so redirect user to https version of this page so https://.../someOtherPage.php. Would that work?
4.To avoid browser popping message "this page contains non secure items..." my links to css, images and all assets, e.g. in case of http://subdomain.mydomain.com/checkoutPage1.php should be absolute so "/images/image1.jpg" or relative so "../images/image1.jpg"? I guess one of those would have to work :)
wow that's long post, thanks for your patience if you got that far and any answers :) oh yeh and I use php/apache on shared hosting
If the SSL termination is on the webserver itself, then you'll probably need to configure seperate document roots for the secure and non-secure parts - while you could specify that these both reference the same physical directory, you're going to get tied in knots switching between the parts. Similarly if your SSL termination is before the webserver you've got no systematic separation of the secure and non-secure parts.
Its a lot tidier to separate out the secure and non-secure parts into seperate trees - note that if you have non-SSL content on a secure page, the users will get warning messages.
Regards your specific questions
NO - whether data is encrypted depends on where it is GOING TO, not where it is coming from
YES - but only if you DO NOT set the secure_only cookie flag - note that if you follow my recommendations above, you also need to ensure that the cookie path is set to '/'
the page which processes the username and password MUST be secure. If not then you are exposing your clients authentication details (most people use the same password for all the sites they visit) and anyone running a network sniffer or proxy would have access.
Your EDIT left me a bit confused. SSL is computationally expensive and slow - so you want to minimise its use - but you need to balance this with your users perception of security - don't keep switching from SSL to non-SSL, and although its perfectly secure for users to enter their details on a page served up by non-SSL which sends to a SSL page, the users may not understand this distinction.
See the first part of my answer above.
C.
I have a web application that uses Integrated Windows Authentication to validate users. Most of them are remote and don't have access to a workstation to update their AD password.
Rather than manually managing passwords my self, I'd like to put together a script so they can change them on their own.
How would I update their windows password through ASP?
If you are going to offer this in a website, you should consider the security implications. A self-service password changing website is generally considered a major security risk and is not common.
You mention that your users are remote. If the site will be public, how will they authenticate through Integrated Authentication? They only way I know to make this possible is through VPN. Otherwise, they will have to use Basic Authentication to enter their username and password. This is very insecure, even over SSL.
Here are some recommendations:
Secure the site using client certificates. If this is not possible use SSL at a minimum.
I would strongly recommend that you implement the actual password-changing logic in a secure webservice. The ASP.NET page should call the webservice to request the change.
You should store an audit trail of password changes. DO NOT store the passwords, just an event log of the user, time, and IP address.
Test very thoroughly to ensure that the integrated security is recognizing your users properly. Make sure that users cannot accidentally change other users' passwords.
There is a function in the System.DirectoryServices namespace that seems to be able to handle this. You will need to add a reference to it in order to use it.
Here is the article on how to change user passwords:
http://msdn.microsoft.com/en-us/library/ms817839.aspx
http://support.microsoft.com/kb/555071
If you can set up IISADMPWD like this, you should be able to change passwords. This is actually an ASP application which relies on a COM component.
Note that IISADMPWD is obsolete and does not ship with IIS 7.0.