Bruce Schneier | |||||||||||||||
Schneier on SecurityA blog covering security and security technology. « ATM Skimmer | Main | German TV on the Failure of Full-Body Scanners » January 21, 2010Web SecurityNice article. Posted on January 21, 2010 at 2:25 PM • 17 Comments To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter. From a skim read it covers the basics reasonably well. It'll take a little longer read and a think to say what should be there that isn't there 8) Posted by: Clive Robinson at January 21, 2010 3:21 PM Someone call the PM! Clive is in trouble! 2 sentences? Clive. Blink twice if you're under duress. Posted by: BF Skinner at January 21, 2010 3:39 PM There's a nod to server languages besides php, but you really have to know your own environment, be it LAMP or J2EE or asp.net/IIS or anything else. The best web code can be undone by a poorly configured server. And a well configured server can be undone by poor network security. It really is a chain of onions. And yes, that has to be the shortest comment I've ever seen from Clive! I think he was just in a hurry to get first post :-) Posted by: Rich Wilson at January 21, 2010 6:07 PM That wasn't Clive. It was a cross-site request forgery attack on Bruce's blog, posing as Clive. Posted by: Carlo Graziani at January 21, 2010 6:42 PM Sorry for offtopic, Bruce, I just thought you and others may want to know about this tidbit: http://archives.seul.org/or/talk/Jan-2010/... "If you use Tor, you're cautioned to update now due to a security breach. In a message http://slashdot.org/submission/1156116/... Ouch! Posted by: Who Mourns For Tor? at January 21, 2010 8:18 PM This blog could be easily twittered. 160 chars are more than enough... :-) Posted by: John at January 22, 2010 2:47 AM The only reason to upgrade Tor, from reading that e-mail, is to get the addresses of a couple of new directory servers. The Tor code and protocol itself was not compromised in the least. In fact, even if the attackers had been attacking Tor (instead of just using the compromised servers for bandwidth) the use of git would have *probably* prevented any surreptitious changes to the Tor source. (Probably, because they're also using svn, which isn't as secure. I'm not sure how they're using them, so I couldn't say.) And as far as I can tell, malicious changes to the source would have been the only possible attack that could have affected the security of Tor users, short of breaking the Tor protocol. The compromised servers were, AFAIK, not Tor nodes of any sort. Posted by: pdf23ds at January 22, 2010 7:04 AM Oops. Two of the machines were Tor directory servers. But the directory protocol is tolerant to a small number of compromised directory servers. Posted by: pdf23ds at January 22, 2010 7:06 AM Pretty good article for an "intro". The focus on PHP would hopefully not be lost on those who do Java, C#, Ruby, Grails, or whatever language of choice. I think some of the issues I take with all vulnerability documentation is the "classification" of issues. A SQL Injection, Command Injection, or XSS attack is the same attack. The only difference is the destination of the data element. The concept is the same: unvalidated input is being sent to an interpretter/processing engine which results in unintended results. I think part of the problem with getting web Security is the inability for people to use the "K.I.S.S" method. We want to make everything sound so complicated, when in reality it really isn't. It just requires effort -- but effort doesn't necessarily equate to complexity. Posted by: AppSec at January 22, 2010 7:46 AM @ B.F.Skinner, Rich Wilson, 3quick blinks 3slow blinks 3quack blinks. (Yup the a is the hidden message 'a'uthenticator 8) All done in time to the "Last Post", The "Rider of Blinky" has been close for the past couple of days but the Anti-Bs have got a grip on it for now and the fresh boild lobster look is dulling. @ AppSec "Pretty good article for an "intro". The focus on PHP would hopefully not be lost on those who do Java, C#, Ruby, Grails, or whatever language of choice." You indirectly highlight a problem I've seen more of recently, which is how to explain a software problem. Once upon a time when I was a not so wee man we used psudo code alla Knuth or whom ever (even ASN1 if we had to) But to get at the people who are most likley to need the advice "you have to keep it real" but you also "have to keep it short and sweet". PHP is let's be honest a dogs dinner of bit's of the banquets of older languages such as C. So the author does get kudos not just for the artical but the way he gets it across. What the article does highlight is another altogether more troubling security problem, which is a mono culture of applications their interfaces and code reuse in the resulting end user applications dependent on them. To understand the way the issue works we need to step back in time fifteen or so years to the mid 90's and see how it all played out. On one hand our problems with the web where just starting with the lack of "state" a series of cludges with major security implications resulted due to the "copying" of "example code" to get around the issue. HTTP was not designed to (nor can it still) handle state. The browsers supporting it where not designed to support applications either. On the other hand the majority OS (MS-DOS) of the time could not either. I need to add a note here that I'm not bashing MS (much as I would like to ;) because this was and still is an industry wide problem and MS where but are nolonger the major problem at the time. MS tried to resolve the Dos Woes by an "application on top" which was called "Windows" to provide mult-application support. After two previous very woefull attempts (any one remember using Windows 2?) the third version started to get traction. This was due in the main to the hardware actually being able to support the idea. However It is important to remember that MS saw the "shining path" as the issolated (except for data) desktop each running MS Apps. MS then under competition from the likes of Ray Norder at Novel moved into the network application world (Win 3.11, NT 3.51/4.0) but only for business users to access data. However that irritating "internet thingy" was begining to become very much used by home users. And MS played catchup/spoiler with IE. However the Internet and especialy HTTP kept moving from strength to strength. MS now under anti competition threats moved IE into windows. Which was (and still is) a major major security issue. IE was effectivly the new "multi-application desktop". But unlike the underlying NT desktop which had some working security measures to isolate applications memory space and threads it had none. A number of people myself included pointed out that the OS security was fairly irrelevant when the Apps where all running under IE which had become the "new OS, without security". You can imagine what a surprise it was to wake up and find not the old and tired tastless and stodgy MS chaff in the breakfast bowl but a nice new lean shiny chrome which architecturaly addressed many of the IE issues (and can solve many of the Internet apps issues as well just via segregation). So historicaly security has risen behind the applications not with them. And for many multitasking environments that apps run in there is no security of any worth. The apps have moved from being relativly begnin objects to being out right attack objects getting in to the heart of where the users have the all important data they are trying to use (and optionaly protect). But the next stage is afoot and that is common apps with poor API's such as the likes of Adobe, MS and many others some as helpers (plugins) and some as presentation extension (applications). For instance a minor change in say flash can have a critical security effect on not just the user but the web apps as well. So call it my "no brainer" prediction for 2010, the industry will conclude that the cloud (so far) non event will be stalled due to application security issues. And where are all these issues going to come from, 1, Poorly designed interfaces. But ultimatly they all derive from "Market imperative". That is the Internet has removed geospatial limitations it is now all about time to market to get the founders market share. @.@ I hope I have made sufficient effort to show I'm not under durance vile (or medical as it was) today 8) Posted by: Clive Robinson at January 22, 2010 10:05 AM This was a good intro-level overview. I found it interesting that the author seems to be addressing web developers on the newbie end of the spectrum, and he seems to take for granted that they don't know a thing about the HTTP protocol or how browsers actually work. I think he's right; I've met plenty of web developers who lacked any knowledge of, or even interest in, the basic technologies their applications rely on. I work with a number of folks who develop for a major application suite that has a sort of pseudo-code, from which server-side Java and client-side Javascript are built. The software being a web application, I assumed the developers would at least have a passing knowledge of Javascript, but that's not the case. Many of them do not even make a conceptual distinction between code that runs on the server vs. the client. I think this phenomenon probably has a lot to do with the sorry state of affairs we're in. Posted by: Mark at January 22, 2010 11:48 AM @ Clive R, Something new for your interest. Remember me to Nick Pat will you? Tell him the Red Team report finally came out. Posted by: Rob Lewis at January 22, 2010 12:09 PM I clicked on the link and got owned. :-} Posted by: Robert'); DROP TABLE Students;-- at January 22, 2010 1:58 PM Honestly, that page seems too remedial to me, yet, I know that people who don't understand any of that are deploying web sites... It kind of scares me really... Posted by: Brian at January 22, 2010 4:49 PM @ Rob Lewis Yes, I remember you. I believe, though, that your DoD claims are somewhat misleading. They probably refer to the "Sai" file server, which is a particular application of Trustifier and one that traditional MLS already handles quite well. Two things: trustifier surviving in such a restricted, well-understood setup doesn't imply it would protect a web server as well; evaluations of trustifier meta-kernel do not mean the "ryu" web security solution is just as secure. In order to truly assure Trustifier, the ryu solution would have to defend against DoD Red Teams and taking down a web application is usually easier than a cross-domain solution. Cross-domain solutions are easy to get right in comparison. I still don't see that DoD report on Trustifier's web site, which is covered in marketing stuff. If you would post it here, I'd love to see the results since the File Server alone may be of use to many companies. Posted by: Nick P at January 23, 2010 1:19 PM Marcus Ranum did a wonderful TED talk regarding the history of HTTP and the state-less design: http://www.youtube.com/watch?v=o59mQhBiUo4 Definitely worth the 20 minutes to check out.... Posted by: george at January 25, 2010 10:26 AM On Trustifier, I must point out that you are in error. Red Team testing and reporting was done with original Trustifier, many months BEFORE ryu and sai were even conceived as separate product offerings, targetted to specific interests of various markets. I strongly suggest that you try at least perform due diligence and verify facts before venturing with misleading info ... and YES, the Red Team did NOT break thru Trustifier protection, even WITH superuser privileges, because the role-centric security rules did not let them, period!!! The Trustifier-protected system was NOT subverted or corrupted. Think on that! Top dog Red Team, stopped dead within their own penetration timeline targets! Sounds like something that should be looked at closely, doesn´t it? There is NOTHING else like it out there. Hence the exclusivity among those selected for the recent SINET presentations to security specialists. If they are looking at it that closely, maybe you should look closer too. Posted by: Eric M at October 29, 2010 7:14 PM Subscribe to comments on this entry Post a comment
Powered by Movable Type. Photo at top by Geoffrey Stone.
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT. |
|
Comments