From the previous discussion, we’ve agreed that software generally is not secure. Typically, rather than writing it for security, it is usually written for functionality. If security is dealt with at all, it’s often handled after the fact. There’s a ton of resources available to help us to monitor the vulnerabilities and the mitigating actions to counter those possible threats. One of the first steps in becoming aware of these vulnerabilities is to write better code, to reduce the dangers. Another step is to really apply the web application security website to the principles of writing coding sequences. There are several organizations which help reduce some of these dangers. There’s OWASP, CVE and CWE, NVD as well as in the United States, the CERT program or organization.
OWASP stands for Open Web Application Security Project and their purpose as indicated on their website, is working with web applications as well as a published top ten list as an overview of more commonly constructed security attacks on web applications, as they happen. These top ten vulnerabilities list is worth looking into. There are more mistakes that developers make and common errors in general as well as exploits from perspective of someone sending out an attack and affecting your computer, especially involving the web applications. The CVE stands for common vulnerabilities and exploit database. Not only does it deal with exploitation, but also possible exposure to an attacker.
The CWE is the common weakness enumeration and that is basically a listing where it goes through all the weaknesses that are out there. This is a way to demonstrate some universality or commonality areas of weakness out there. NVD is the national vulnerability database. The last one, called CERT is the one which goes along with computer emergency response team. The CERT is more involved with government systems and computers. These very different sets of resources and each is quite good for their unique characterizations about which can be utilized, depending on what it is that you are programming for.
So, going back to the OWASP list, this was published in 2013 as a possible more current list, and in terms of testing material, you won’t be asked as to which of the list is the fifth one down. But, instead they’ll give you a kind of attack and expect that you can describe and explain that specific attack. This discussion will allow not only understanding about attacks and vulnerabilities, but also how to mitigate those. Also, could be said to form a countermeasure.
The OWASP stands for the Open Web Application Security Project and they have just a wealth of information. In terms of testing material as associated with this concept, there should be answers to what is code injection, what is meant by cross site scripting attack, what is meant by miss configuration, etc. So, let’s work through the OWASP top ten and then see how to mitigate each of the possible attacks with more specific strategies for each possible attack as listed on the top ten list. This particular section will house the first five and the next section, Module 4 part 6 will house the last five.
For the first question, of what is meant by an injection attack, there are a number of possible attacks via code injections. Whether it is SQL, OS, or LDAP injection, whatever that’s being exploited, any time we allow user input in the increase of added functionality for the user’s web experience, then we allow for them to have the opportunity to put command codes and possibly have them running in the back end database. These codes can be malicious and so forth. As an example, we might have a query for the user to input their name on the first webpage, and then the second webpage comes up and says something like “Welcome, (insert user name)” . This place that’s allowing the user to input information could very well be an open door for someone who wants to put in elements to mess up the webpage, the software, the physical machines.
Instead of actually putting a name in that field entry,a person could put coding to command dropping the table in a SQL database, then that’s ending up affecting the back end database. This is a kind of code injection. This is especially easy if there is no form of input validation. Some ways to mitigate this potential threat of code injection is to enforce input validation. There should be limits to the data field in terms of limiting first in the form of alphanumeric versus a dropdown menu. The user shouldn’t be inputting any alphanumeric forms of data in the datafield. Another is to limit the length of the data field. Instead of allowing 500 characters, for example, only allow 10 characters for maximum length. One more limitation for inputting is for example the state abbreviation or any other abbreviation for that matter, to put them in a list of drop down menus rather than allowing say 100 characters for the user to input. The less opportunity you provide for the alphanumeric type of input, the less likely to have an opportunity for hostile code or for the potential threat from code injection.
The second one is broken authentication and session management. If the developer doesn’t plan this out, then it is possible for an attacker to step in after a while and pick up on the session information and then impersonate the user. For example, when does a session expire? When there’s a certain amount of inactivity, what happens with the session? Is it possible for someone else to step into the middle of it? That would be a great point to impersonate and exploit the session management if it hasn’t been handled properly. We have to make sure that we are authenticating and doing that function well so that the various forms of sensitive information via session identification information is not ex-filtrated off the website.
The third one is cross site scripting. So, a website that has protected against this will ask questions, confirming who you are. So, for an example, rather than inputting a name in the data field, where it asks for your name. Instead, I input malicious code instead. The next page that comes up is going to house that malicious code. So, for instance an attacker sends an individual a phishing email, that takes the user to a site that’s been compromised, and it’s already too late. The user now has this corrupted code that because of the way that cross site scripting works and because the website doesn’t really do anything about validation, then just by clicking into the phishing email, then that malicious code is already running in your browser. The cross site scripting is a very difficult attack to resolve for the client. So, in a poorly written website, then the attack can be very effective. So, it’s better to have that input validation as a way to reduce the likelihood of this kind of attack.
The fourth common attack is the insecure direct object references. For an example, an individual who has been authorized to access certain figures from a certain month through to the end of the quarter, but not authorized to view the following month’s figures. For example, from January to April but not May. but in the URL, there’s an indication like “=Jan” where easily the Jan could be replaced with “May”. So, the person is accessing information that they really don’t have the authorization to do, by simply manipulating some aspect in the URL bar.
That is referred to as insecure direct object reference. Some of this would be pretty easy to limit, but first the developers have to be trained in writing more secure code to begin with. We’re basically asking them to write a webpage, and not necessarily think ahead and write the secure code. Since that historically has been the typical view, then the webpage which we are asking them to build, so we can sell our product. Since that is the focus, then it makes the whole thing easier to escalate privileges because the typical webpage doesn’t have this fixed, and so it’s the direct object reference as the attack. The individual is choosing to manipulate the URL rather than going the more legitimate pathway of clicking on the links and navigating properly throughout the actual website.
Fifth, is one of the more common vulnerabilities associated with web applications. It is known as security miss configurations. This is a very broad topic but default settings usually can allow anonymous access. For a web server, we want people to be able to access the website and buy our product or perhaps learn about our company without having to go through too many steps from our managers and supervisors. We want it to be fairly easy but we also need to think about requiring a more secure environment by integrating for example, authentication with certificates and so on in terms of the miss configurations.