I feel like I’ve made some great progress this week which only makes sense because of the absurd amount of time I’ve been putting into the project. This week I was able to get LDAP authentication working with the Pitt main campus domain controllers, Professor Ellison has introduced me to some different penetration testing tools to harden the site, and I spent a considerable amount of time on the inventory edit form. I’ll talk more about this in the coming week.
LDAP, Lightweight Directory Access Protocol, is a great way to provide authentication to my users for a couple of different reasons. Firstly, the users do not technically need to worry about yet another internet account. I say technically because they will have to apply for an account to the Student Activities database for account approval, but the good thing is they are able to use their existing University of Pittsburgh credentials. Another reason for this is that the database associated with the website will not have the responsibility of holding user credentials, which is a weight off my back.
First the user must request an account. Once they’ve done this, all of the site administrators are alerted that there is a pending account awaiting approval. Once approved or denied, the user is notified and, upon approval, now has access to the site with their Pitt credentials. They enter their credentials into the login and the website forwards those credentials out to Pitt’s domain controller. If the domain controller authenticates the account, the site now cross checks the database to make sure that the username has an active account. If this all passes, they are assigned a session of either user or administrator privileges, depending on their status in the database, and are able to access pages accordingly.
A test version of the site is now up and running on the web server. Since security is always a top priority, it is imperative that the site is as resistant as possible to any type of exploits, such as SQL injections and other XSS (cross-site scripting) attacks. A SQL injection is every database administrator’s worst nightmare. A SQL injection can take place when a user enters malicious code into a normal search query.
For example, most web sites have a search function. Typically the user just types in a normal search string, clicks the search button, and the results are displayed. If the website is not programmed to deflect SQL injections, a user could enter a search term such as : “blue jacket;drop table person”. By entering a semi-colon, the SQL query could see that as a delimiter and start a new command. The SQL command to delete a table is “drop table”, and if there is a table called “person” in the database, when successfully executed, the whole table (and all of its data) can be permanently deleted. This is just one example of a SQL injection, so it is easy to see how important it is to not be vulnerable to such attacks.
Although I am learning fast, I am not yet a PHP master. Luckily, several free tools are available around the web that will run mock XSS attacks on your pages and alert you to what problems are, which Professor Ellison has been happily running against my site, and yes, there are some issues. However, they are rather easy to fix and are more time consuming than anything. The ultimate goal is to have a secure, perfectly functioning site. The last thing anyone wants is to spend weeks, months, or years performing data entry and preserving records all to have someone erase them with the click of a button. Of course there will be backups, but you get the idea.