Your company creates a custom web application and deploys it live. I bet it went through some serious security testing, and even the development process had security in mind from the design stage right (it should have). So if all this effort is put into a custom web application, why isn’t the same being done for your company’s blog? Blogs are nothing more than web applications. And unless you created your own blog engine from scratch, you are using some third party solution (WordPress or TypePad). This means you’re trusting the software is free of any vulnerabilities and has been developed with secure coding techniques as well. It’s one thing to insist your developers use secure coding techniques but it’s[…]
Category: software
Authoring web sites was a lot easier in the 90’s…write some static HTML, maybe some JavaScript, and you were done. Need to update the site? Just edit the HTML pages and upload. In the past decade or so, web applications have made a lot of progress with interactivity and dynamic content. Services hosted outside of the application container, such as third party web services and databases, can provide a boatload of flexibility when designing and implementing a web site. But, these services rarely, if ever, allow anonymous interaction…so we need to go back to our old friend, the password. Passwords are usually stored in a configuration file along with a web application. The configuration files are generally not made accessible[…]
Many people will claim that the “openness” of open source software helps make it secure. With an entire community given access to all of the code, it makes sense that programming errors or security issues would be recognized often. And thanks to tools like Findbugs, many issues are found and fixed before, during, and after a product is released. Products that rely on security through obscurity or snake oil solutions generally fail to hold up in an open source environment… but I think this can be a double edged sword. With the common perception of open source software as being “more secure” than their closed source counterparts, there also exists the possibility for people (and companies) to place too much[…]
Many of you may have heard of the massive DNS patch release coordinated by Dan Kaminsky. What you may have also heard is that the details of the vulnerability and the patch would be released at Black Hat this year (two weeks from now). This has been one of the few patch releases that had such widespread secrecy around it. Very few people knew about the patch until Windows (and OS X and Linux) asked them to update. Now that the patch is released, the code can be viewed, and compared to the old code and people can figure out what the problem is. It took a while, but several people have done just that. There are some generally accepted[…]
Google announced that it has released ratproxy their passive web analysis tool. It kind of “rides along with you” in order to determine what areas may be an issue. Since it can “ride along”, it can also scan restricted areas requiring authentication. It’s not a replacement for some of the more active scanners – webscarab and paros but it could certainly help the more casual user determine potential issues. It doesn’t, however, let you fiddle with the HTTP request/responses as the other proxies do. Play with it, see how you like it before adding it to your arsenal, but I think it will be a great addition.
Throwing an application into production and performing vulnerability assessment is utterly useless. Not placing security controls into your software development life cycle (SDLC) is like rolling out a new car design without performing crash tests. So what kinds of defenses does the average web application need? Here’s a good way to figure it out. Take a look at the common application security vulnerabilities and then list the security controls that developers need to prevent those holes. You’ll end up with a list that includes authentication, session management, access control, input validation, canonicalization, output encoding, parameterized interfaces, encryption, hashing, random numbers, logging and error handling. Many companies, especially smaller ones are reluctant to implement such controls or develop security policies. It’s[…]