Web Application Security, A Beginner's Guide Quotes

“The Wizard, the Giant, and the Magic Fruit Trees: A Happy Ending When we last visited our hero the wizard, he was in sad shape. Vandals and thieves had wrecked his magic fruit trees, and so he conjured up a lava moat to surround the enchanted orchard and keep the intruders away. Unfortunately, the lava moat also kept out the good villagers who came to the orchard to pick fruit (and, not coincidentally, to buy potions from the wizard). To solve this problem, the wizard invited his friend the giant to live in the orchard. The giant was tall enough and strong enough to jump over the lava moat, so whenever one of the villagers wanted a piece of fruit, he could simply shout his request to the giant and the giant would fetch the fruit for him. This would have been a perfect solution and a happy ending to the story, except for the fact that while the giant was indeed very tall and very strong, he wasn’t particularly smart! The giant followed the wizard’s instructions to the letter—which were simply to serve the villagers’ requests—so when a sneaky young man came up to the giant and asked him to fetch the wizard’s collection of magic scrolls, the giant happily complied and unwittingly gave up all of the wizard’s precious secrets. The wizard—correctly realizing that the fault was his own, not the giant’s—sat the giant down and set down some better rules for him to follow. “Never trust the villagers,” the wizard said, and explained that the giant should only serve villagers’ requests for fruit. The wizard didn’t bother to list out all the things the giant shouldn’t serve, like scrolls or crystal balls or wands; he knew that if he tried to list out forbidden objects, he would inevitably forget one. No, the better approach was simply to state what was allowed and not what was forbidden. Furthermore, since the giant had no legitimate need to ever go up into the wizard’s tower, the wizard cast another spell that prevented the giant from entering there. That way, should an even sneakier villager try to break the rules again (“Fetch me the fruit that’s sitting on the wizard’s desk”), the giant would be unable to comply. With these new rules in place, the giant did a much better job of preventing troublemakers from stealing the wizard’s secrets; the villagers got their fruit faster since the giant wasn’t off running malicious errands to the tower; and the wizard slept better at night and sold more potions. And they all lived happily ever after.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“The activities defined by BSIMM don’t come directly from the BSIMM authors’ experience in creating secure software; instead, the authors interviewed security executives at 30 organizations with world-class software security initiatives and created the BSIMM activities from the commonalities that those organizations reported. So the security testing activity to ensure that quality assurance engineers include edge case tests in their test plans comes from the fact that most of the 30 organizations interviewed also perform this activity. As a result, BSIMM is not meant to be prescriptive; it is only meant to be descriptive. Instead of thinking of it like a cookbook full of recipes, the BSIMM documentation states, you should think of it like a trail guide full of waypoints.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“Note Both BSIMM and SAMM are rooted in the same research; Pravir Chandra has referred to the projects as forks.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“Some web development organizations, particularly those following Agile development methodologies, don’t like this advice. “You Ain’t Gonna Need It,” they say, quoting the YAGNI principle of waiting until you definitely need a feature or plan before starting to work on it. “Who knows if we’ll ever get attacked? Working on a plan now could end up just being wasted time. We’ll deal with this issue if it ever happens.” That’s fine—if you don’t mind getting your team together for an ad-hoc scrum meeting at 3:00 A.M. on Christmas morning.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“Security expert Jay Beale, currently Managing Partner, CFO, and Chairman of InGuardians Inc, explores this same topic (and comes to the same conclusion) in his paper “‘Security Through Obscurity’ Ain’t What They Think It Is.” Jay states that obscurity isn’t always bad, it’s just bad when it’s your only defense. He goes on to give an example: Suppose you have a web application serving sensitive internal company data. If your entire defense of this application consists of hiding it by running it on a nonstandard port (maybe port 8000 instead of 80), then you’re going to get hacked. Someone will run a port scanner against this server, find the application, and steal all your confidential data. But assuming you do take proper steps to secure the site, locking it down with strong authentication and SSL, then running it on a nonstandard port certainly wouldn’t hurt anything and might raise the bar a little bit.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“Programmers often refer to making function calls as “issuing commands” to the system. This is a Web 1.0 mindset. You may be able to think of server-side code as “commands,” but when it comes to client-side code, you can only offer “suggestions.” Never forget that an attacker can alter your client-side logic in any way he wants, which means that all the really important decisions need to be made on the server, where you have a better chance of guaranteeing that they’re made the way you want them to be made.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“The way xp_ cmdshell works is very simple: It takes a single string argument and then executes that as a command-line call. For example, the call would perform a directory listing of the server’s C drive. Again, at this point the damage is limited only by the attacker’s imagination, and exploiting this through SQL injection is absolutely trivial: If you’re running SQL Server, we strongly recommend disabling or removing the xp_cmdshell stored procedure. You can disable it through use of the sp_configure stored procedure, like so:”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“Applications treating data as code is the root cause of almost every major class of vulnerability. Cross-site scripting happens when applications treat data as HTML or script. SQL injection happens when applications treat data as SQL. Buffer overflows happen when applications treat data as assembly code.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“when applications treat data as code, applications get hacked.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“The reason for this is what is called the “time of check to time of use” problem, or TOCTTOU for short (also sometimes seen as just TOCTOU). The idea is to minimize the interval between these two times, because an overly lengthy interval can create the potential for abuse.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“Time of check to time of use. The very best time to make server-side authorization checks is as close as possible to the time when an action is to be taken.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“The strongest guarantees of security come from server-side authorization, precisely because it is the server that mediates interaction with the resources managed by the application. The server is thus the last line of defense for those resources. The further out from the data store a component is, the more vulnerable it is to compromise, which is why servers should fundamentally not trust any subject until that subject proves it is trustworthy.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“One problem with DREAD is that all of the factors are weighted equally. An ankle-biter attack rated with a damage potential of one but all other factors of ten has a DREAD score of 8.2 (41/5).”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“While you could solve this kind of problem by pulling out all the non-critical features of your application and just developing a bare-bones product, that wouldn’t be a great solution. Features sell products.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“a still simpler definition of attack surface is that attack surface is all of the features of your application. Every time you add a new feature to your application, at the same time you’re adding a potential point of failure and a potential means for an attacker to compromise your system.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“In terms of the validate-early or validate-late debate, while I do see merit in both arguments, I have to come down on the side of the late validators. Again, it’s a matter of trust. When you validate early, every other module or routine that processes the data has to trust that the validation actually was performed and was performed correctly. A colleague of mine refers to this as the “Lettuce Issue.” She says that while the grocery store may claim to sell you pre-washed lettuce, she always washes it again herself before she makes her salads, since that’s the only way to really be sure. The same principle applies to input validation: give that user input a good thorough washing right before you use it.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide

“The key takeaway from this is that it’s impossible to defend the server-side logic of a web application by implementing defenses on the client side.”
― Bryan Sullivan, Web Application Security, A Beginner's Guide