CSSLP Tutorial: Module 04,Part 06 – Open Web Application Security Project(OWASP) 6 through 10

Web Application Security

On the OWASP top ten list, there are several threats and vulnerabilities which we haven’t uncovered yet in our discussions.  These all range from ways that sensitive data can be exposed, modifying information in the URL, CSRF attacks and mitigating strategies to avoid them, using recycled code that has deprecated, and receiving redirection from a website to get you onto a malware site.

So, number six is sensitive data exposure.  This is a pretty broad term in that there’s probably millions of ways to do this, but the specifics for what is listed at number six involves potential phishing requests and other attacks where there is compromised user information, that is sensitive in nature.  So, perhaps we are using the HTTP instead of https to transmit data from our web server.  This doesn’t properly protect the data that’s in transit and may possible only protect the data at rest.  Sensitive data includes credit card numbers, health care information for specific individuals, authentication credentials, and so on.  For example, LinkedIn  profiles website lost somewhere around 5 million passwords, Target and Home Depot both were compromised for their credit card accounts.  These sets of data were being exfiltrated off of the internet, siphoned from the various websites, and it just takes additional training for avoiding phishing attacks as well as other types of social engineering.

 

Number seven on the top ten list is where the access control is missing some functional level.  This is very similar to insecure direct object access, where a person modifies a section in the URL and then able to access a location that they shouldn’t be able.  This ability to access might be tied to the function level access control.  Restricting access to certain sites and activities based on the person’s role, then the user could easily change the parameters in the URL, and then not just access those areas that are supposed to be restricted, but also access functionality like going to websites that administrators are supposed to go, therefore retrieving administrator privileges over the location.  This would be more about gaining access to unauthorized actions rather than as the insecure direct object  being about accessing potentially confidential information.

CSRF attacks, also known as cross site request forgeries, are where an attacker can compromise information of a session like its ID, the authentication credentials of  that session, and so forth when we are setting up a connection to a trusted site.  If that information is compromised, then the attacker can send out the stolen information as if it were their own and complete a forged request.  The aspects of saving passwords in the browser or using cookies which are a storage but in an unsecure manner, or of using the same browser for visiting a chatroom at the same time of visiting confidential information, and clicking on hyperlinks in email, and so on.  No password should ever be saved in the browser, no hyperlink should be clicked when they‘ve been sent to your website and read your emails in plain text. When you are finished with a session that had required a password, make sure to log out of the session so as not leave it open for potential compromise. Don’t ever just close the website. You want to make sure you are logged out of the session first.  Limit the way that session IDs are stored. Many of our time-saving techniques can end up hurting us in the end with these cross site forgery sessions.

One of the mitigating strategies is to implement software where specific token is connected with each unique session.  These tokens should be produced in an unpredictable, random order.  Additionally, the CAPTCHA’s can help to maintain some randomness where you are to enter the text into the box and that proves you’re no robot.  Some are upper and lower case together, in the field text.   Sometimes, they are a little difficult to read and that’s because the developers are wanting to make sure that it is a human and not a robot answering the page.  So that’s a way of getting random, non predictable session ID’s,  by basing them off of the CAPTCHA.   They must be unique and not replaying old information from previous sessions. CRSRF attacks can be mitigated based on what the developer  does as well as what the end user does as well.  The concept revolves around maintaining uniqueness of the session information and then that way reduce the likelihood of attacks and compromises.

The ninth vulnerability is associated with vulnerable component usage.  Many times, there is access to information frameworks such as libraries, frameworks, code and other software that has been deprecated. There may be millions of lines of code, and you find a way to recycle some of the code that’s already out there and does the task you want it to, for that part of your program. However, you have to be careful, because if it’s an older code that has already deprecated and is unsecured or banned as an API , you could run the risk of having a security vulnerability.

The last one of the top ten list on the OWASP’s top ten is when you go to a website and it redirects you to another website you didn’t ask for.  For example, going to the BOFA on the URL and then that website redirecting you  to go to bank of America.com.  We want to make sure that the redirection is validated and trusted.  So, the manner can also be considered as valid as well for our assurances.  Otherwise, we are at risk for threats as well.

So, the previous section (part 5) and this section together make the complement of describing the OWASP’s top ten list. This is a great organization to produce the list to help out the web application community.  This is as a summary from the 2013 top ten of the vulnerabilities of web based applications so that you can have a sense of what each of the problems are and what possible strategies could be used to help when faced with these problems.