This report shall detail the development, testing and evaluation of the secure website, including an explanation of the security measures in place and how they help protect data.
The website is required to be moved by the admin before the SSL is functional, it will be accessible here: https://www.wbsserver.co.uk/litt110
To login as an Administrator and access administrator section please login with the following and then access the members section:
Newly registered accounts only have access to products and members section.
A 4.0 framework version of website has been provided on disc, this version has been configured for local testing, and it is recommended this version be used for local testing as some elements such as the navigation menus work better.
Although not used for development, the site was made with the intent of using an SSL certificate when it was uploaded to the web server. Using an SSL certificate allows for transfers between the server and the client to be encrypted, this guarantees the security and integrity of any data in transit over the server (Verisign, 2010). Securing the website with an SSL certificate was important, as there was login details involved on the website. This made encrypting login details in transit important as stolen login details can be damaging, especially if they belong to an administrator or member of staff as they could be used to cause damage to the database and other parts of the website.
At the same time the site does not use SSL for every page, it is instead only used for secure pages, as using SSL for every page increases the server load which will cause the website to load slower.
The website uses two SQL server databases for dynamic content and user information. The user information database is based on the default ASP.net security template, and contains information about users, including roles and login details. The second database is a products database containing product information.
The ASP.net user database contains encrypted passwords, this is to prevent a hacker from gaining access to the database and then being able to see all the users login details in an unencrypted format, it also stops administrators from having full unhindered access to user passwords and details, as it is unlikely they will need access to this information, instead users can reset passwords themselves. The database contains a one way hash of the userâ€™s password which came with the default Microsoft security database (Microsoft, 2006).
The Products database was not secured, this was because it contains no sensitive information, and so unauthorized access would not lead to a harmful data breach.
All SQL statements on the website are handled by .net controls or SQL parameters; this is to prevent SQL injection attacks on the website.
According to (Microsoft, 2009) SQL injection attacks occur when a hacker attempts to inject harmful SQL statements into controls or parts of the website, for example: a hacker may attempt to type a statement such as DROP TABLE â€œUserDataâ€Â this would delete the UserData table, causing many problems and damaging the websites operations. Parameters and the default .NET data controls all attempt to avoid this problem by having restrictions on what can be entered, and restricting SQL access.
Another part of the SQL statements is the transaction statements, rollbacks and commit statements are used on every SQL statement, this is less a security concern and more of data integrity and exception handling feature. Using rollback and commits prevents database changes being committed to the database if errors occur; erroneous changes can be undone or rolled back (Microsoft, 2010).
The website makes extensive use of login views and other login controls, there is a login state control on the top of every page, which will tell a user if they are logged in or not, there are also login view controls on many pages such as the product page, which will tell a user to login if they are not logged in, or show them the products if they are logged in.
User Roles were used as part of the security on the site, the three designated user roles were Administrator, Staff Member and Customer, the roles were picked based on the fact the site was made as a store. Administrators were given access to a special page that allows the insertion of new products into the database and the editing of existing ones, and customers simply have access to the products page. Different access levels were an integral part of the sites security. Administrators were also given access to an image upload page, which is validated so that only image files can be uploaded, the validation works by checking the file extension based off suggestions by (Microsoft Technet, 2005).
If a user does not have the correct access level to view a part of the website, they are redirected back to the homepage.
Passwords were considered an important part of the sites security, and as such the strength of passwords were changed from the default 6 characters to 8 characters. Stronger password rules was considered to be very important to stopping brute force attempts and also making passwords harder to guess (Microsoft, 2010) the password rule was also thought not to be too stringent, which could lead to security vulnerabilities such as people writing down passwords.
Testing was performed by the author using a detailed test plan and log, the website was tested for security and functionality. (Please see Appendix for Test plan/log.)
Security was tested by attempting to bypass user security, this was done by logging in as users of each role and attempting to access parts of the site such as the administration section, the same tests were repeated whilst not logged in. Also tested was the sites vulnerability to SQL injection attacks and attempting to access secure parts of the website over a non-secure connection.
Site functionality was tested by running through many tests, testing such things as the ability to access parts of the site, to validation on things such as text fields. Site functionality was considered less important than security for the purpose of this website.
Testing was performed on both local and remote hosting when appropriate, due to server problems only theoretical SSL testing was possible.
Major problems encountered during testing:
These were major problems encountered during testing (See appendix for minor problems)
Web server Framework
The site failed to correctly load pages once deployed to the webserver, this was found to be an error related to the .net framework due to the error that came up which was related to the target framework, according to (Microsoft, 2010) this meant the framework of the server was not the same as the website, the version deployed to the website was converted to 3.5, a physical copy of the superior 4.0 version was retained as several features such as navigation menus had to be cut down to work with 3.5.
SQL Error 26
This was a result of a web configuration problem (Microsoft, 2009), as the author did not have access to the administration section, they uploaded the databases to their own ASP.net server and added remote connection strings, and this resolved the problem.
The web server would not load SSL/HTTPS pages, due to admin access problems server side. The author was not able to resolve this problem; however the author tested the SSL redirection feature on the local host, and found the feature did work and should, in theory, work fine on a configured remote server.
There were several things that may have been done differently during the development of the website or alternatively went well.
One problem during development was the lack of SSL during testing, which meant that the security could not be fully tested this was never resolved as the SSL setup on the server could only be accessed by an administrator.
One element of the SSL that did go well was the author finding a C sharp code segment that would automatically use HTTPS instead of HTTP if the site was not being debugged/run locally, this made the transition to web server easier, as links did not have to be changed all over the site, and the code could simply be added to any page that needed to be kept secure. The author considered this easier than setting the individual links to HTTPS, which would have made debugging hard.
The biggest flaw of the development and site, is the lack of functionality, the security was easy to implement as there was a lack of functionality on the site, making it easier to implement. If there had been more functionality on the website, the security features would have been harder to implement, however the site also would have been more functional and would have had more content.
Server problems made the website difficult to test, but this was outside the authorâ€™s control. The author did the best they could to work around server problems, which were often caused by a lack of access to the admin panel, for example the author uploaded the databases to their own webserver. The author tested HTTPS redirection on the local host; however the author could not test the actual SSL security on local host, as there was no certificate.
Security in transit can be defined as keeping the data of the site secure whilst it is being transferred between client and server, and other connections. The transit security was handled by the SSL certificate, which encrypts all data in transit. One problem with the data security in transit was that, using SSL encryption on every page causes the pages to load slower, as such there needs to be a balance of security versus performance, the author only made the login and member pages use the SSL/HTTPS protocol, this kept performance of most pages high and made sure that only secure pages were slowed down by encryption.
Security in storage can be defined as keeping any sensitive stored data on the website secure. The author kept data security in storage by using default encryption that came with the default ASP.net security settings; this encrypts the password and several other tables in the database (Microsoft, 2006). The author believes that the security on the storage of login details was weak, and a stronger method of encryption would be needed for a proper data driven website that would be holding more personal details, such as the addresses or credit card details.
Verisign, (2010), Secure Sockets Layer, Available Online From: <http://www.verisign.co.uk/ssl/ssl-information-center/how-ssl-security-works/index.html> Date accessed: 10/12/10
Microsoft, (2010), SQL Injection, Available Online From: < http://msdn.microsoft.com/en-us/library/ms161953.aspx> Date accessed: 10/12/10
Microsoft, (2010), COMMIT TRANSACTION, Available Online From:< http://msdn.microsoft.com/en-us/library/ms190295.aspx> Date accessed: 13/12/10
Microsoft, (2005), Uploading Files in ASP.net 2.0, Available Online From: <http://msdn.microsoft.com/en-us/library/aa479405.aspx> Date accessed: 14/12/10
Microsoft, (2006), Building Secure ASP.net applications: Authentication, Authorization and secure communication, Available online from: <http://msdn.microsoft.com/en-us/library/aa302398.aspx> Date accessed: 15/12/10
Microsoft, (2010), Password Policy, Available online from: < http://msdn.microsoft.com/en-us/library/ms161959.aspx> Date accessed: 15/12/10
Microsoft, (2010), Target a specific .NET Framework Version or Profile, Available Online From: <http://msdn.microsoft.com/en-us/library/bb398202.aspx> Date accessed: 03/01/11
Microsoft, (2009), Troubleshooting Server and Database Connection Problems, Available Online From: <http://msdn.microsoft.com/en-us/library/ms156468.aspx > Date accessed: 03/01/11