Reference no: EM131123748

Discussions- OWASP Top 10 - Revisited

The OWASP Top 10 continues to be a good reference for helping us understand common web application attacks and the potential impact.

Using the most recent OWASP Top 10 (From 2013). Pick one of the top ten (don't include SQL injection since we covered that last week) and provide your own unique summary of the issue. Here is a link for review:

https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013

In your summary be sure to include a detailed attack scenario and details to prevent this attack. Dig deep to find out more details than those provided in the reference article. Reference your sources.

Also, include your assessment for the technical and business impact.

Comment on other student posts to provide more clarity or suggest additional details not covered.

So please do what is needed for my post itself first and then comment on student A & B labeled on the attached document called Week 8 Discussions.docx.

My discussion:

Student A: A8 - Cross-Site Request Forgery (CSRF)

Created by Roland Branham

This type of attack is basically where an un-consenting victim is forced to send a forged HTTP request to a website (Auger, n.d.). To be successful, the hacker typically exploits the trust between the victim and the website (Auger). It is hard for the target website to know the difference between forged and actual HTTP requests as long as they are coming from a "trusted" browser (Acunetix, 2016). Essentially, to achieve his or her desired objectives, the hacker will use the victim's credentials and the victim must be authenticated with the target website. Some additional names that CSRF is referred to are "XSRF, one-click attack, session riding, confused deputy, and sea surf" (Auger). This seems like some especially sneaky hacking in my opinion.

Scenario:

There was an interesting example mentioned by Acunetix (2016) in which a victim visits a chatroom in which a hacker placed a CSFR link; this could cause money to be withdrawn from the victim's account if the victim is authenticated with the target website and clicks on the link. Often these links are not seen by the victim because they are hidden in hidden forms or they are embedded into image files. Here is an example:

<img src="https://captialbank.online.com/transfer?account=Gates&amount=1000000&for=Branham">

or it could be a link that is kind of camouflaged like this:

<a href="https://capitalbank.online.com/transfer?acct=Gates&amount=1000000&for=Branham">Click here to see nude celebrities!</a>

Technical Impacts:

"Moderate" according to OWASP (2013). Just about anything that the victim is authorized to do can be set up to occur. A hacker could even order pizzas on the victim's Papa Johns account using CSRF, but there would be no guarantee of exactly when the pizza would arrive because it would depend on when the victim unknowingly submitted the forged HTTP request. They could post a very nasty thing on your account and it would look like you posted it.

Business Impacts:

According to OWASP (2013), this is "application / business specific." It could impact your reputation; but the severity would obviously depend on the amount of users affected, loss, and the visibility /media coverage. Another issue is trying to determine whether or not the user intended to perform the action. Someone could fabricate a CSFR attack claim after their own ignorant transaction. Depending on the amount of loss, the company may or may not choose to do a thorough investigation or risk going to court over the allegations. Its interesting that the http requests info isn't stored somehow on the server side. Maybe it is and I just haven't learned about that yet.

Prevention:

Use unique tokens in HTTP requests, at least a new one each new user session (OWASP, 2013). Other ways are to make sure that users re-verify that they are actual users, such as through a CAPTCHA (OWASP), and to use tokens (Acunetix, 2016). Users should logout out web applications when no longer using them (Acunetix).

OWASP. (September 18, 2013). Top 10 2013-A8-cross-site request forgery (CRSF). Retrieved from:

https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)

Auger, R. (n.d.). Cross site request forgery. The web application security consortium. Retrieved from:

https://projects.webappsec.org/w/page/13246919/Cross%20Site%20Request%20Forgery

Acunetix. (2016). CSFR attacks, XSRF or sea-surf - What they are and how to defend against them.

Retrieved from: https://www.acunetix.com/websitesecurity/csrf-attacks/

Student B: Security Misconfiguration

Created by Thomas Hodges on Jul 5, 2016 7:17 PM

Summary

This week, I'll choose Security Misconfiguration as my topic from the OWASP Top 10. Security misconfiguration is very relevant to me, because I'm coming from a system administrator role, and moving towards a full-time developer role. Doing things like keeping the operating system and applications up to date, along with ensuring that only necessary services are running and account passwords are changed regularly is something that I'm all too familiar with. But knowing how a developer needs to also keep up to date with the latest third-party libraries and separation of components within their application is something I haven't considered.

Attack Scenario

A simple scenario would be to say that the default service accounts are being used with their default passwords. However, that is all too simple to talk about. I've seen plenty of custom-made web applications return very detailed stack traces regarding an error, including the inner and outer exception blocks. An attacker could use that information to gain knowledge of the system, like variable names, in order to try to either break other parts of the application to gain more knowledge or break in.

Preventing the Attack

In order to prevent this sort of attack, and at the same time prevent unwanted outsiders from gaining valuable information about the application's code, is to only return an error message or error number. I would keep these error numbers documented, so that when a user reports an issue, it can simply be looked up, and they are none the wiser. Most likely, if a user is receiving an error that could return a stack trace, there is little they could do on their end to resolve the problem anyway.

Technical Assessment

From a technical standpoint, it would be rather annoying to implement this measure while a product is still development. However, it will get the developers used to knowing what their error codes mean, and if they are keeping up with the internal documentation. I would not suggest turning this measure on at the last minute, as documentation could be lacking and rather unhelpful.

Business Assessment

Any knowledge of internal procedures, especially pieces of an application's source code, is detrimental to the operations of the business. This sort of measure will not impact business operations in any way more than if a user received an error without a stack trace. So for my assessment, implementing a measure to return error messages instead of stack trace is a sane decision.

Source:

https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration

My discussion:

Student A: A8 - Cross-Site Request Forgery (CSRF)

Student B: Security Misconfiguration