tag:blogger.com,1999:blog-13756280.post3430051655690538499..comments2024-02-08T03:44:23.780-08:00Comments on Jeremiah Grossman: Time to start blogging again...Jeremiah Grossmanhttp://www.blogger.com/profile/05017778127841311186noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-13756280.post-65935473674340481692010-05-13T23:20:19.647-07:002010-05-13T23:20:19.647-07:00>> "Developers will not code against a ...>> "Developers will not code against a class of attack that they both don't know of and respect."<br />Completely agree. Maybe in the futue releases of the report you will find possible to include time slices with framework slices for Perl/PHP?<br />For example, the usage of constantly updating Drupal, Wordpress and Joomla CMSes would be a good explanation why CSRF did not make for Top Ten for PHP...<br /><br />However, thanks for your effort, which was an excellent food for thought! :)Anonymoushttps://www.blogger.com/profile/10803765980668812597noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-69418011692403467702010-05-13T22:27:03.542-07:002010-05-13T22:27:03.542-07:00@Andrew, "Yes, I wanted to know exactly this:...@Andrew, "Yes, I wanted to know exactly this: that "abuse of functionality" was measured only within PE web sites."<br /><br />Good question, It was not. All websites were lumped together regardless of the type of Sentinel service. The breakdown of how many websites are covered under which service type is definitely a reporting blind spot. I'll take that as feedback for the next report and will publish it. Right now reasonable estimates are about 75% PE, 20% SE, and the rest BE (~5%). Will confirm in the next report.<br /><br />Taking that into consideration it should be safe to assume that under PE websites only, Abuse of Functionality would measure 25% higher than their current overall numbers -- I think, but not certain.<br /><br />The assumption about bad/good programmer distribution might not be accurate. While we can yet correlate it, an alternative theory is that what a website is vulnerable to has a lot to do with WHEN it what built. Developers will not code against a class of attack that they both don't know of and respect.<br /><br />For instance take the average site launched in 2005 vs. 2007, we think there will be a significant difference in XSS issues between them (the Samy Worm). Or from 2007 to 2009 with regards to SQLi Injection (the mass SQL worms). <br /><br />As time progresses programmers have shifted for a variety of reasons to using the more "modern" framework, like .NET and Structs over plan Perl. If the above theory is true, it would make it seem that Perl is "not as secure" as the others. Again, just another theory worth considering.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-43242816915796890742010-05-13T22:10:23.170-07:002010-05-13T22:10:23.170-07:00Yes, I wanted to know exactly this: that "abu...Yes, I wanted to know exactly this: that "abuse of functionality" was measured only within PE web sites. <br />The reason I asked this question is that I tried to interpret the statistics in different ways and failed. One thing that I cannot understand is the variance of the likelihood of busines logic flaws, i.e. "Abuse of Functionality". It differs from 8% in ASPX and Struts to 25% in Perl. <br />If we assume that the distribution of "good", "average" and "bad" programmers is the same within each technology (ASPX and Perl), then one would expect that the likelihood of flaws not addressed by frameworks (i.e. Abuse of Functionality) will be around the same. But the report clearly shows that it is not so. Wrong assumption? <br />And yes, I understand about brochure web sites. I thought that they were not under PE contract but rather SE or BE one...Anonymoushttps://www.blogger.com/profile/10803765980668812597noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-88626898677745872402010-05-13T15:14:16.011-07:002010-05-13T15:14:16.011-07:00@Andrew, I think I know what you are asking, but l...@Andrew, I think I know what you are asking, but let me answer in a bit different way. <br /><br />Lets assume 50 of 100 websites we assessed were found to have XSS. With this in mind figure 6 means that of the 100 websites, they have a 50% likelihood of at least 1 XSS issue.<br /><br />To your question about "Abuse of Functionality", we check for it on all websites managed under the PE service, whether or not the website might have features potentially prone to the issue -- clearly some do not. This would include brochure ware websites and we do discuss this in the report. So, this percentage is of ALL websites. <br /><br />That what you wanted to know?Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-12144195750058001092010-05-13T10:28:25.144-07:002010-05-13T10:28:25.144-07:00Just wanted to ask for a clarification. In Figure ...Just wanted to ask for a clarification. In Figure 6 (Top Ten Vulnerability Classes) the percentage value for each vulnerability class is counted as Sum(Pj)/N, where Pj is 1 if web application has vulnerability of the specific class and 0 otherwise.<br />My question is about N for business logic flaws, for instance "Abuse of Functionality". Is it the total number of web sites with the specific techology or is it the total number of web sites with the specific techology with the appropriate contract (i.e. PE for business logic flaws)? <br />If it is the first choice then the statistics is skewed...<br />It would be great if this issue was covered in the report :)Anonymoushttps://www.blogger.com/profile/10803765980668812597noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-47575595561441012212010-05-12T08:34:30.989-07:002010-05-12T08:34:30.989-07:00I haven't gotten a chance to read the report y...I haven't gotten a chance to read the report yet, but I can say one thing with certitude - at an organization where security is merely an afterthought (if that), whatever framework has the most effective default settings in place will be most secure. We have code in classic ASP, ASP.NET, and JavaEE, and far and away, the ASP.NET code holds up the best. Why? Because the developers don't do anything to it, and it's a bit more secure than when they treat code from other frameworks the same way.<br /><br />Yeah, it ain't where we want to be - maybe the survey is mainly of organizations who've historically had more security awareness than mine - but a lot of organizations start out with little concern for security; once they become worth attacking, they have to go back and fix whatever is not protected by default.Calandalenoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-40491439065959288172010-05-08T16:05:33.854-07:002010-05-08T16:05:33.854-07:00also that xss hack works on windows 7 with firefox...also that xss hack works on windows 7 with firefox 3.6.3 well done :)Unknownhttps://www.blogger.com/profile/11035184621125509870noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-81535023443768701192010-05-07T16:05:36.209-07:002010-05-07T16:05:36.209-07:00In my opinion, a language or framework by itself w...In my opinion, a language or framework by itself will never be able to solve the problems faced when it comes to web app security. Certain things can be done to make things easier for the developer, but nothing can really solve the problem on its own. At the end of the day, it comes down to the way in which the developer uses the language or framework, and as every developer will tell you - there are a lot of ways to accomplish the same thing.<br /><br />I think this is somewhat similar to implementing safety features in cars. The manufacturer can do everything they can to make the car safe, but if I choose not to wear my seatbelt and drive 90 miles an hour down a slick road at night, nothing is going to save me when I hit a brick retaining wall.Matt Pressonhttps://www.blogger.com/profile/02537815584811632732noreply@blogger.com