The modern world is more connected than ever and therefore needs more security than ever. As developers we should always secure our applications in every way we can. Most hacks are preventable by implementing simple security measures. In part 1 of this blog last month, we discussed some of the first steps in securing applications. This blog will continue by discussing more techniques used in securing applications.
Two-factor authentication is one of the most successful security measures in preventing accounts from being compromised in today’s world. As its name indicates, two-factor authentication is a two-step process. First, a unique passcode or key is generated when a user wants to log in. A different passcode is generated each time so that no login attempt is ever the same. The application or device generating the unique short-term code is only accessible by the account holder. Second, the user is also still required to login with their normal, stagnant private credentials like a username and password. In order for a hacker to compromise a person’s account they would not only need access to the person’s username and password, but they would also need the authenticator key that is generated upon login attempt. This method is very effective in preventing accounts from being compromised because it goes a little off the grid while also still using an algorithm shared by the “grid”.
XML External Entity Processing (XXE)
XML documents have the ability to load information from external resources. This leaves XML open to an attack known as XXE because the resource being loaded could be compromised and/or the information specifying to load external data could be malicious information. This type of attack usually involves loading some external malicious code that retrieves login information to the machine running the application. To prevent XXE attacks, simply disable the ability for XML to load external resources in the code. You should be able to quickly Google how to set the loading of external resources to disabled and see a code snippet based on the programming language being used in your application.
Encrypt Sensitive Data - (2 way)
Encrypting data involves transforming data to a jumbled state while also being able to reverse the jumbling back into plain data. This prevents people with access to data from having access to sensitive information. A person with access to sensitive data trying to collect Social Security Numbers would have to determine how to decrypt the data in order to retrieve the actual SSN. Any sensitive data should be decrypted and encrypted on every use. This is extremely relevant to DBA’s, sysadmins, and developers because these positions are often given a lot of access to accounts and data. A DBA with privileges to a SQL Server shouldn’t be able to simply open up a table in a database and plainly read sensitive information. The information should be encrypted to ensure safety and security in the minds of all parties involved. There are several ways to encrypt the data as well. Most of the time it will come down to a design decision or preference by others on the project. There are new features in SQL SERVER 2016 like “Always Encrypted” that would allow the encryption to be handled on the SQL side. Another solution would be to handle all encryption in the code of the application.
Application Level Roles/Permissions
Applications almost always have some sort of authentication to determine whether someone can access a system. Applications should have a more detailed breakdown of what users are allowed/denied access to inside of an application. Maybe someone in HR or accounting should access the payroll system but accounting should not have the ability to add, edit, or remove employees. Both HR and accounting would be authenticated to access the payroll system but only HR could access the employee management section of the application. A role system keeps information more secure and allows even more control over who accesses what.
Applications occasionally have requirements to save/load information using a file path and the file system. This functionality opens an application up to a directory traversal attack. A directory traversal attack is where the file path or filename is manipulated in order to navigate the malicious attacker to their intended target to and retrieve sensitive system information. This could allow an attacker to access a machine, retrieve an administrator password, and compromise a company. If an application needed to load an image from the C:/application/images/ folder but the file path is manipulated the user can navigate different directories and system files. Surround the filename with a path from code rather than user input or remove unwanted characters from the path or filename and you can prevent directory traversal.
Social Engineering Training
Social Engineering is the one hack that cannot be prevented using technology. A social engineering hack involves person to person deceptive communication to obtain information. One of the most common scenarios would be where a hacker wants access to a network. The hacker could call an employee, impersonate technical support, state that they need to do a security check up on their account, ask for the employee’s username and password, and the untrained unaware employee’s account information has just been compromised. Two-factor authentication is one of the best technological methods of defense against social engineering attacks but if an employee is untrained or gullible enough then it may still not be enough. The best defense against social engineering is thorough training. Train employees to NEVER give their account information to ANYONE. Often times social engineering hackers will impersonate co-workers or 3rd party consultants. Thoroughly educating your employees to recognize who they should and should not give information to is the only way to keep information secure.
After this two-part blog series you should have insight into how to keep your applications secure. I didn’t go into huge technical detail on each method because they are handled differently per language most of the time. Not every application needs every single step we discussed and in fact, some techniques are very specific and won’t apply everywhere. If you have any other questions about some of the methods discussed, feel free to send me an email (email address below) or even google them yourself and you may find a more technically detailed explanation. I hope this two-part post was either educational or a useful refresher so now it’s time to go out into the world and make the most secure apps around!
If you enjoy this topic or enjoy talking about development of any kind you should check out our available positions at Sparkhound. Sparkhound is full of people with aligned interests and motivation to provide the best possible solution to any scenario. There are plenty of great minds to lean on and we like to have fun too! Feel free to contact me at firstname.lastname@example.org and/or contact Sparkhound for any further discussions, questions, or feedback. Woot!