Securing our website
Let's start at the beginning. A few years ago, we developed an application that was web based. It assisted corporate customers in managing their purchasing needs. The application has security built into it in the form of a user ID and password. Very early in the deployment we discovered that if a user logged into the system, browsed to a document (PDF) or a data page, they could copy and paste the URL in to another browser andsee the document or data with out having to log back in. So, we purchased an application that protects each secure resource and validates that the user has a login cookie in the browser before passing the request to our application. If the user tried to copy and paste the URL into a browser without the secure cookie, it prompts the user for credentials before displaying the information. Very similar process for most web sites. For instance, if I log into my checking account, view my transactions page and then try to cut and paste the transaction page URL into another browser, my bank login page appears not my transaction page.
So now, to the problem, the product we currently use is very expensive and for very large customer it becomes cost prohibitive. The data we are securing is not national security stuff, no Credit Card numbers, no Social Security Numbers, not personal information, just data about what that company buys and what it pays for the products. It certainly is confidential, but doesn't need this level of security. So how can I prevent the security problem above without costing an arm and a leg?
So now, to the problem, the product we currently use is very expensive and for very large customer it becomes cost prohibitive. The data we are securing is not national security stuff, no Credit Card numbers, no Social Security Numbers, not personal information, just data about what that company buys and what it pays for the products. It certainly is confidential, but doesn't need this level of security. So how can I prevent the security problem above without costing an arm and a leg?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I agree with zstapic.
What you have just described is a complete lapse in proper coding standards, as testing in your companies developers and testing team.
The fact that it was approved to go online with such issues already shows there's something wrong with your software development life cycle.
I believe this is an issue with your development life cycle, and the problem should not be fixed by purchasing another product to cover it up.
To fix the problem I have a few suggestions:
1. Build staff competancies
Send your developers for some training in developing web applications (most course now a days have a few dedicated modules to security). Better still, if you can send them for courses on developing "SECURE" web applications.
Also, send them for course on security and the software development life cycle.
Hire project managers that are aware of the secure development life cycle.
Some references:
http://msdn.microsoft.com/en-us/library/ms995349.aspx
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1174897,00.html
2. Building up the competancies of your developers takes time. So, you'll need tools that are able to test your application and verify it's correctness. Tools such as static code analyzers come to mind, there are many good ones out there. I recommend (and have personally used):
www.parasoft.com
www.fortify.com
They have automated code analysis and unit testing which actually test your applications as if you were running. The draw back is they do *almost* cost an arm and a leg.
But, you'll need to invest *some* money into IT security. Expertise does not just fall from the sky and onto your lap.
Hope that helps
Kelvin
What you have just described is a complete lapse in proper coding standards, as testing in your companies developers and testing team.
The fact that it was approved to go online with such issues already shows there's something wrong with your software development life cycle.
I believe this is an issue with your development life cycle, and the problem should not be fixed by purchasing another product to cover it up.
To fix the problem I have a few suggestions:
1. Build staff competancies
Send your developers for some training in developing web applications (most course now a days have a few dedicated modules to security). Better still, if you can send them for courses on developing "SECURE" web applications.
Also, send them for course on security and the software development life cycle.
Hire project managers that are aware of the secure development life cycle.
Some references:
http://msdn.microsoft.com/en-us/library/ms995349.aspx
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1174897,00.html
2. Building up the competancies of your developers takes time. So, you'll need tools that are able to test your application and verify it's correctness. Tools such as static code analyzers come to mind, there are many good ones out there. I recommend (and have personally used):
www.parasoft.com
www.fortify.com
They have automated code analysis and unit testing which actually test your applications as if you were running. The draw back is they do *almost* cost an arm and a leg.
But, you'll need to invest *some* money into IT security. Expertise does not just fall from the sky and onto your lap.
Hope that helps
Kelvin
Agreed. The use of sessions is what you need (and indeed what should have been in place from the start). There's a good rundown of some of the methods of session management at http://www.technicalinfo.net/papers/WebBasedSessionManagement.html.
Of course, you'll need to learn how to implement sessions in the language used by your application. There's also good information at OWASP http://www.owasp.org/index.php/Session_Management
Of course, you'll need to learn how to implement sessions in the language used by your application. There's also good information at OWASP http://www.owasp.org/index.php/Session_Management
Just make sure to read that OWASP link and not just implement isset($_SESSION as mentioned as a base/start example above. Session hijacking is actually a fairly common practice among attackers, especially when someone can eavesdrop on your network connection in some way.
Some think that implementing secure protocols for your web traffic (ie SSL/TLS, SFTP, etc.) would protect you against that. However, now you're talking about securing that traffic and hoping you didn't implement it wrong. In ways where I could force normal traffic over your non-secured protocol in various ways through MiTM techniques.
We also need the session to regenerate on login. Otherwise I might be able to send you a link or force a query that actually sets my own made-up session when you login.
Some think that implementing secure protocols for your web traffic (ie SSL/TLS, SFTP, etc.) would protect you against that. However, now you're talking about securing that traffic and hoping you didn't implement it wrong. In ways where I could force normal traffic over your non-secured protocol in various ways through MiTM techniques.
We also need the session to regenerate on login. Otherwise I might be able to send you a link or force a query that actually sets my own made-up session when you login.
http://www.ssi-developer.net/htaccess/htaccess_protection_file.shtml
Make sure to also deny access to this .htpasswd file and place it outside of your website's root directory.