Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : Over the past few weeks, I've been looking at the OWASP Top 10 and thinking back to my time spent as the Sys Admin for a SMB. As the technical resource at the company... web app development also fell on my shoulders. This wasn't simply building the company website, as I worked for a marketing company this included full blown web applications for clients. Now prior to joining nCircle, I lived and breathed security... it was (and still is) my passion. This isn't the case for Sys Admins and developers at other SMBs and even larger enterprises. Security is often an afterthought.... sometimes a "way-afterthought". For these people, the ultimate resource to turn to is the OWASP Top 10, the ten most pressing concerns in web application security decided on by experts in the industry. The OWASP Top 10 "represents a broad consensus about what the most critical web application security flaws are" and the people at OWASP "urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws." I don't disagree with this, if everyone takes the steps to prevent these flaws, we'll have a safer online world. That being said, given the OWASP stated purpose of the Top 10, I don't feel that it is written to best represent everyone who uses it. The Top 10 often feels as though it is written by industry experts for the rest of the industry. This isn't, in my mind, what the document was intended to do. The Top 10 may be referred to by pen testers or web application researchers to reference, but it's primary goal is to raise awareness and provide assistance to developers. Many of these developers aren't security oriented and simply write code... look at the colleges and universities, they have programs pumping out plenty of web developer grads who have never seen a course on secure coding. Usability is number one is many of their projects. It is these people that I feel the Top 10 fails... it doesn't give them something they can easily work off and to me that should be the primary goal of a project such as this. Let's take a look at two scenarios. Scenario #1 Imagine you work for a small marketing company with less than 30 employees. You are the sys admin with all the regular sys admin duties, however you are also tasked with the responsibility of building web applications and/or web sites for customers and for use within the company. You have limited time and take the OWASP Top 10 as your guide to securing the application you are building. You aren't security oriented and someone pointed you toward the document. If you first tackle A1 (XSS) you'll read the following: "Cross-site scripting, better known as XSS, is in fact a subset of HTML injection. XSS is the most prevalent and pernicious web application security issue. XSS flaws occur whenever an application takes data that originated from a user and sends it to a web browser without first validating or encoding that content." You follow the advice of "Ensure output is passed through htmlentities() or htmlspecialchars()" and continue on to the next line item A2 (Injection Flaws). Here you read this description, "Injection flaws, particularly SQL injection, are unfortunately very common in web applications. There are many types of injections: SQL, Hibernate Query Language (HQL), LDAP, XPath, XQuery, XSLT, HTML, XML, OS command injection and many more." As stated you aren't a security person, this is a job that you ended up in but one of the things you notice is the mention of HTML Injection. Why does that sound familiar? Oh yeah, A1 was a subset of HTML Injection... well I've protected against A1, that must mean I'm good here and you move on to A3. STOP! How about we look at the other types of injection (perhaps SQL Injection) and protect against those as well. Right now, reading this, you are thinking that no one would ever do that... but it happens. Now why does it happen? A1 is XSS and A2 is Injection Flaws. XSS is a subset of HTML injection which is a child of Injection Flaws, yet it's also been made a peer of Injection Flaws. There is a logic flaw that exists here and it is enough to cause confusion for many people. Scenario #2 Now let's imagine that you are an enterprise with separate teams for Development, System Management and Security Auditing. Company policy states that audits must be done before Web Applications go into production and again immediately after going into production. The criteria for the audit is defined by the OWASP Top 10. Development and QA have done their part and the application is audited internally. The application passes audit (no vulnerabilities according to the Top 10) and sent off to System Management for deployment. The system is deployed and a follow-up audit is performed. Again no issues are found and the web app is live. Two months later a report comes in that your web app has been blacklist for serving malware. An investigation ensues and sure enough, live malware is being distributed... the website is pulled down and forensic investigation reveals that a flaw in the server software was used to upload malware to the server. If the auditing team had been using the 2004 edition of the Top 10, they would have discovered this flaw, however Insecure Server Configuration was removed from the 2007 edition of the list. Now as I said, I've been considering the Top 10 for quite some time, and both of these potential situations have caused me some concern. Last week I started to consider this write-up on the subject and instead decided to contact the Top 10 mailing list to discuss these issues. While the readdition of Insecure Server Configuration seems to have been well received the problem that I see in XSS and Injection Flaws has not. I understand that the people responsible for this list are considered industry experts and I don't meant to slight anyone by making the suggestion that the current list is flawed. That being said, since a new version of the list is planned, that means the current iteration isn't perfect and that there is room for improvement. I believe that this area is one of the areas where improvement can be achieved, but I'm not so full of myself to think that because I believe it, it must be true. I fully understand that in the past, it made sense to distinguish between XSS and SQL Injection, they were two major issues that needed recognition. I'm not sure though that the categories XSS and Injection Flaws properly represent the issues at hand. With more and more people referencing the Top 10 and the PCI Security Council leaning heavily on it to define web related portions of the PCI-DSS, I feel we need to make it as clear and concise as possible. That being said, there are three ideas that I feel more properly describe this situation: 1) Drop Injection Flaws from the list, if the important items are XSS and SQL Injection and we don't want to combine them for fear of a loss of importance, then why lump SQL Injection in with anything. XSS and HTML Injection are closer than SQL Injection and HTML Injection yet they are not defined in that way. So A1 would be XSS and A2 would become SQL Injection. 2) Merge XSS into Injection Flaws. Make Injection Flaws A1, leaving A2 open for the current "risk de jour" and lump them together in a way that makes them technically accurate and easier to understand. 3) Create the OWASP Top 20, or two separate Top 10 lists. One that identifies the buckets of larger groupings (Injection Flaws) and the other identifies the specific vulnerability classes (XSS, SQL Injection, etc). As I said, this didn't receive the warmest welcome on the OWASP Top 10 list, but I can't help but wonder if it's a matter of the experts not being able to place themselves in the shoes of the people using the list. This is a common and easily made mistake in our industry, we become so comfortable and familiar with the material that while it makes sense within our own grouping, we forget that the material needs to be referenced and acknowledged by people that don't live with our mindset.






Les derniers articles du site "360 Security" :

- Microsoft Enables Drive-By Downloads in Firefox
- Adobe Responds To Criticisms About Its SDLC
- FBI Citizens' Academy, Week 5
- Some Thoughts on the OWASP Top Ten
- Why Common Risk Scores Matter
- May Patch Tuesday - Fear Not the 14 CVEs
- FBI Citizens' Academy, Week 4
- RSA 2009 Recap
- The Count is not the Thing Counted
- RSA Virtualization Security Panel Review

---

S'abonner au fil RSS global de la revue de presse

---