During this week’s class, one of the main topics we discussed was the OWASP Top 10. If you’re proposing to perform an application scan that uses the OWASP Top 10, how would you justify that rationale? Also, how would you answer if they questioned you about whether you were going to scan for CSRF vulnerabilities, which are not part of the 2017 release of the OWASP Top 10?
Reader Interactions
Comments
Leave a Reply
You must be logged in to post a comment.
Dan Bilenker says
The OWASP top 10 represent the 10 most common IT security vulnerabilities, and is updated yearly to reflect emerging threats. My rationale would be that using the OWASP top 10 is an excellent starting point for evaluating baseline vulnerabilities. The vulnerabilities that OWASP represents can also serve as gateways to deeper issues. Using the top 10 is a way of evaluating the current security posture of an organization, to be used as a mechanism for exploring deeper issues that may exist.
If asked whether or not I were going to scan for it, I would reply that after I conduct the initial scan using burpsuite, we could dive down and use the burpsuite CSRF tool.
Vince Kelly says
…..great point about the OWASP 10 potentially uncovering other, more deeply ingrained problems Dan. I think that’s a very important engineering principle – i.e., that problems have a tendency to occur in clusters and that single large failures are usually rare and easily spotted. Catastrophic failures are usually the result of a chain of much smaller faults occurring in some unknown, unanticipated or unintended sequence. OWASP 10 seems to be a good jumping off point when trying to identify larger issues.
Dan Bilenker says
I’ve rarely seen errors occur in isolation, where one singular issue is the sole point of failure. Generally, vulnerabilities are exploited on many levels, but the entry point is the biggest point of failure. There’s usually a domino effect in these situations.
Duy Nguyen says
The Open Web Application Security Project (OWASP) is an open community with the purpose enabling organizations to better secure and maintain their applications. OWASP provides organizations with tools and documents for a better understanding of application vulnerabilities and risk. It also provides tools and recommendation techniques on how to best mitigate weaknesses. The OWASP Top10 is comprised of 40+ submissions of specialized application security and industry surveys, including vulnerability lists gathered from hundreds of organizations and over 100,000 implemented applications and APIs. The group continuously updates vulnerabilities with new flaws and changing methods of attacks.
OWASP top10 is the top 10 reported vulnerability based on organizations surveyed. It’s a good starting point but should not be limited to the only source of identified vulnerabilities for the organization to recognize. There are other vulnerabilities that need to be carefully considered and mitigated. Cross-Site Request Forgery (CSRF) is an attack that occurs when authenticated users are forced to execute unwanted actions on web applications. Once completed, CSRF inherits the identity and privileges of the victim to perform malicious requests on the victim’s behalf. Since the victim has already been authenticated, there would be no way for the application to distinguish between malicious requests or legitimate requests sent by the victim.
Vince Kelly says
Good point Duy on how easy it is to hide CSRF in a Web page. To the user/victim being attacked, all they would see is an innocuous looking button or link highlight. All the attacker needs to do is to employ a little social engineering Phishing or Spear Phishing effort to get them to click on what the victim thinks is a legitimate site but is actually the attackers site – something that allows the attacker to grab their legitimate session token. The only way that the victim could know that it was a CRSF attack would be to literally look at the HTML source for every page and be able to associate/spot the suspicious incongruency between what the link value was in the tag and what its description was…….,and we all know that ain’t gonna happen!;););)
Vince Kelly says
HEY, WAAAAAAAIT JUST A SECOND HERE!!!!
I just noticed that the blogging software that we are using for this class is vulnerable to XSS attacks!!! The last line of the post I just entered SHOULD have read, (I’ll escape the actual HTML tag that I used in the sentence:) ;
“…..between what the link value was in the < a > tag and what its description was…….,and we all know that ain’t gonna happen!;););)”
But instead, this blogging software fed back the sentence as a LINK! LOL! That’s awesome!! a security class that relies on insecure vulnerable software! Totally ironic, don’t you think?:);););):)
Dan Bilenker says
Not as ironic as the Webex session hosting the class on ethical hacking being hacked… But yea its certainly ironic.
What did you do that caused your post to return a link (which by the way is un-clickable despite flashing when hovered over)?
Did you enter that post as plain text?
Vince Kelly says
yes – its an HTML ‘anchor link’ I forget the exact syntax but its something like this:
tag link link description end tag
I’ll escape the example so that it shows up, but it goes something like the following::
<a href=”https://go_somewhere_bad.com/” > Click this link so I can hack you! </a>
This is ok but,
…. a *secure* application should have seen that I was just typing in text and automatically ‘escaped’ the special characters but instead this el-cheapo software actually interpreted what should have been text as an HTML command.. It only shows a highlighted (unclickable link) because I didn’t embed a URL.
Click this link so I can hack you!
Vince Kelly says
…..this should blow up if you click the link b/c obviously I don’t have a site called go_somewhere_bad.com but you can see that if I called the link something like :
“Click this link to make a lot of money!” and the victim did, then they’d be in trouble. But THIS software should be able to account for the fact that I’m doing something bad like that. If this junky package was feeding a database then I could type in some SQL commands or HTML commands that would get played back at whoever logged into that system after I had embedded that stuff.
Dan Bilenker says
Interesting! So essentially, you were giving an example of the formatting for the code, in a PT entry form, and the input box still read it as HTML.
If this doesn’t work, I apologize…but what if I typed:
Click to win $10,000
Dan Bilenker says
the link won’t work because I fat fingered a comma into the address – http://www.cnn,com instead of .com. But still, I was unaware you could embed HTML inside these input fields.
Vince Kelly says
Exactly right Dan. You can see that the anchor:
href=http://blah.blah.com
could point to an attackers site but the link description:
“Click to Win $10,000”
could get a user to click that link because the blogging software SHOULD have been looking at/validating what is being input by the user but it doesn’t – this is called “sanitizing user input” and its a BASIC 3rd grade programming best practice that our blogging software doesn’t follow!
So if you enter HTML syntax instead of a simple text message,
you can do evil stuff like this.
The point I was trying to make earlier was that the only way an innocent user could see if the link that they were clicking on was legitimate (MAYBE) was if they looked at the HTML source for the page, found THAT particular link and then identified if it was valid or evil – which is not going to happen.
For example do the following,(I’m using Firefox for this example but you can do the same thing in chrome or IE – they’re just different key sequences):
The link to the community page that we are using/viewing is this:
community.mis.temple.edu/mis5211sec701fall2018/2018/11/01/owasp/#comments
open up a separate tab in your browser and cut and paste the following into the address bar:
view-source:http://community.mis.temple.edu/mis5211sec701fall2018/2018/11/01/owasp/#comments
Notice the link is prefaced with “view-source:”
That tells the browser to dump all the source code that provides the actual display structure of this page.
This will display the entire source code of this session and you’ll be able to go down thru it and see things like:
-where the page is looking for input,
– if there is any Javascript embedded in the page
– if there are any hidden fields that don’t get displayed,
– each persons comments
– how the browser formats the text
you can also just do ctrl-f and enter the specific text that your looking for (this is what the hackers do)
If you go to line 290 you will see my initial example where I used the proper escape characters around the ‘evil link’
Now if you go to line 293 you’ll see my actual evil link
If you go to line 336 you’ll see your evil link to www,cnn.com Click to win $10,000
Jonathan Reid Kerr says
I was also unaware that you could embed html tags in the blog. Though it was something I had thought about and wanted to see if it was possible. You beat me to it!
Vince Kelly says
If you’re proposing to perform an application scan that uses the OWASP Top 10, how would you justify that rationale?
I’d point out that OWASP was originally created to raise awareness among developers and managers and that it quickly became one of the de facto application security guidelines. Today the SDLC has completely changed with more and more organizations choosing to adopt agile development methodologies like the Scrum process methodology. Unfortunately, agile makes no accommodations or considerations for security and emphasizes practices that are an absolute anathema to security. For example, the agile philosophy emphasizes speed over an iterative, methodological application design process, working code over documentation, impromptu and direct customer interactions over adhering to previously negotiated contractual obligations. In addition, the agile philosophy not only emphasizes but actually encourages scope creep during Scrum sprints and hackathon events.
Given all of this, OWASP is a free and easy way to ensure application and code stability without slowing down any existing processes. Integrating the OWASP Top 10 as a mandatory user story that is always made part of the product backlog, Scrum backlog and/or a Kanban board ultimately adds to code stability and customer perceptions that your company knows what its doing.
Also, how would you answer if they questioned you about whether you were going to scan for CSRF vulnerabilities, which are not part of the 2017 release of the OWASP Top 10?
I’d need to scratch my head and ask them why they would NOT want to make sure that they’re not allowing an attacker to impersonate a user or customer by stealing their session tokens. This is a well-known vulnerability and just because it didn’t make the 2017 OWASP Top 10 doesn’t mean that it’s no longer a significantly dangerous vulnerability.
I think an analogy might help to make the point; As of 2018, there have been 519 criminals who have been placed on the FBI’s 10 most wanted list since it was first published in March of 1950. But that doesn’t mean that there have only been 519 criminals operating in the US since 1950 :););)
Dan Bilenker says
“I’d point out that OWASP was originally created to raise awareness among developers and managers and that it quickly became one of the de facto application security guidelines.”
It always seems like the best tools were developed for one thing, then hijacked by everyone else.
Also “just because it didn’t make the 2017 OWASP Top 10 doesn’t mean that it’s no longer a significantly dangerous vulnerability.”
Good point, I think sometimes people take these lists as gospel and then ignore everything else.
OWASP just represents whats currently being seen most frequently.
Brandan Mackowsky says
Vince,
I really liked your analogy about the FBI most wanted list. It is interesting to think about how many vulnerabilities exist and which ones became large scale vulnerabilities/attacks. I think your analogy really shows the affect that there are thousands of criminals that have since operated in the US over the last 60+ years but only a fraction of those were considered high profile, while their crimes still remain crimes. I think it shows the importance of why it is still important to seek out vulnerabilities that may exist, even if they are not considered the most crucial.
Brandan Mackowsky says
The OWASP Top 10 for 2017 serves as a platform formed by the open community dedicated to enabling organizations to work with applications and APIs that can be trusted. In order to justify utilizing a scan that uses the OWASP Top 10, it is important to simply reference it’s background and reason for existence: to serve the community in an unbiased way. When forming OWASP, it maintained a freedom from commercial pressure which allows the group to provide an unbiased and practical gathering of information regarding application security. Using this information in a scan, it is justifiable to scan for the items in the OWASP Top 10 from 2017 because it provides us an unbiased view of what we should be looking for in application security at the current state. These top 10 items are what the OWASP group finds to be the most important pieces of application security in the modern era so it provides justification as to why it is beneficial to look for these items in security since it seems to be the most current prevalent threat. If questioned about scanning for CSRF vulnerabilities, I would explain that it is still important to seek these out in scans because while it did not make the 2017 OWASP Top 10 list, it is still prevalent and can occur within the realm of vulnerabilities and it is crucial to continue seeking these alongside the OWASP Top 10.
Jonathan Reid Kerr says
The OWASP Top 10 is a great resource for those in IT security. It has many of the most common and often dangerous vulnerabilities, including how they work. It serves as a good guideline for ensuring baseline application security. It is put together by security experts and even highlights ways to prevent these vulnerabilities in applications.
When using the documentation, it is important to keep in mind that not all vulnerabilities are listed in the report. When addressing the inclusion of vulnerabilities not listed in the OWASP report in my scans, I would highlight that I would only be using the report as a guideline. There are other vulnerabilities that I would be scanning for that can have a large impact on an organization. I feel like the OWASP report is a great resource, but can blind some to other vulnerabilities and exploits that exists in web applications. All relevant vulnerabilities should be accounted for, even if they are not included in the most recent OWASP report.