Hi Brian, do you know latest NoScript development versions feature specific anti-XSS countermeasures?

Current build is stable enough to be considered a release candidate.
You can get it here:
http://noscript.net/getit#devel

Thanks Giorgio, yes, I've mentioned noscript many times in past blog posts and online chats, I just spaced on doing it here. Noscript is great, and I'd recommend it for anyone using Firefox, but it doesn't really address security on sites that you've decided to trust: that's essentially the main problem here.

the correct spelling is "christey"

Brian, you're right: NoScript can't protect you from "persistent" (AKA type 2) XSS on trusted sites, i.e. if the attacker manages to save its malicious code permanently on the trusted sites.
The only remedy for these ones is the web developers fixing their vulnerabilities.

But the new anti-XSS NoScript countermeasures do protect you from "reflected" (type 1) XSS, i.e. on the fly attacks cast from untrusted origins and landing on trusted sites, e.g. to steal your authentication cookies.
These are the most common and less detectable XSS attacks, and latest NoScript versions are likely the first effective attempt to address them from the client side.

It does not much matter whether it is security or not: if you are to produce good software you need to handle both the expected and the unexpected; you need to cope when things are working to plan and when things go wrong.

I lost the thread there... You have Rohit saying there are three problems, then you mention SQL injection, and the rest of the article is about XSS. Did I miss the third?

Ryan -- Sorry...the three were buffer overflows, insufficient user input filtering, and improper integer handling.

Buffer overflows? Still? To quote Bruce Schneier (in another context) a buffer overflow is
"the easy-to-use low-hanging-fruit automatic-tools-to-fix kind of security vulnerability. It's not new or subtle; buffer overflows have been causing serious security problems for decades. It's an obvious, stupid-ass programming mistake that ANY reasonably implemented security program should have caught. ... This is a software quality problem, pure and simple. And the real solution is better software design, implementation, and quality procedures, ..."

The same is true of user input filtering and improper integer handling as well.

Doesn't managment get some of the blame for shipping products that aren't perfect.

How many programmers have wanted more time to finish but have been told to "ship it now".

A security programming skills test misses the point completely. Successful software security is dependent on both design and coding skills. This test ignores design. Focusing on one without the other is a fool's errand.

What happens in the instance where significant numbers of programmers fail the test at one of the companies that has "committed" to this? Mass firings? What happens if this pass/fail information gets leaked? Bye bye, customer base, hello lawsuits.

Let's be clear, this is a revenue source for SANS, designed to play upon the legitimate fears of IT managers - nothing more.

It's not a panacea, but anything that brings security problems to the forefront can't hurt. Unless you do the same kind of programming day in and day out you can get rusty or forgetful. I'm saving this article so I can go over it more carefully and I will be watching the SANS initiative and probably participating, although I've been programming for almost 30 years.

Perhaps we're due for a reminder that having a degree in a field as broad as Computer Science does not mean the graduate possesses significant knowledge about specific competencies such as designing software that is designed for public facing services. Just like not every M.D. is qualified to be a surgeon, or any of countless other examples.

The Wikipedia article for Computer science defines it as "the study of the theoretical foundations of information and computation and their implementation and application in computer systems". I don't see anything in there about security or programming, let alone the combination of the two.

People need to take accountability for their own mistakes. If you hire a programmer simply because they have a Computer Science degree, and let them write complex software that will be used by hostile users, and don't appropriately supervise that project, you will get burned. I'd even say you deserve to get burned. Blaming someone else for this is cowardice.

With that said, kudos to anybody taking steps to approach the problem with a sensible solution. While I haven't looked into the SANS proposal, I am encouraged by the idea that some folks are interested in being part of the solution, as opposed to simply pointing their finger at someone else.

Ah, but some buffer overflows, input validation, and integer errors ARE subtle, which is why they're still around, even in the most rock-solid software. It is exactly this kind of perception error that the programming exams will label with a big fat "F".

Anonymous, I don't get your point. If the testing makes programmers aware of security errors they might be missing, how is it bad? How will the test determine a perception? Seems to me you either catch the problem or you don't, and if you don't, it's good to find out about it. Over time, keeping up with the types of errors the test is looking for will help you remember to watch for the subtle errors you may have been missing or even forgetting otherwise.

I agree that part of the problem is related to a general lack of training for software developers. However, based on experience, I've found that the other half of the problem is directly related to the amount of "schedule pressure" that is placed on the development team. It's one thing to know how to write code securely, it's another to be given the amount of time that is needed to develop and implement the proper security controls.

I happen to be a SANS/GIAC certified programmer (GNET), and I definitely agree. If we let the sort of sloppiness we have in software engineering go into home and road engineering, we'd be dying off in droves from accidents.

I think we can all agree that schedule pressure affects code secureness. I don't remember where I heard it first (perhaps Ken Beck's first Extreme Programming book?) but it had a quote similar to (I apologize for any mangling) "There are four variables in producing software: features/functionality, quality, resources, and schedule. Management can never choose more than three with the development team choosing the fourth." While I have some strong reservations about Extreme Programming as a general paradigm, the statement is all too true. Management typically dictates features, headcount and schedule and, unless they are more generous than I've ever seen, development will adapt by cutting quality. I think we can all agree that low quality programming leads to less secure programs.

I won't attempt to say that is X% of the problem. But it is certainly less than all of the problem.

As others have pointed out, some people just don't get security. I remember having a fight at a conference where I was presenting on security with an audience member who tried to convince me that a company only needs one firewall and that once inside everything should be optimized for performance and security should be omitted altogether. And this audience member had the fight with me in the middle of my presentation, it wasn't like he was embarrassed by this philosophy or something. I've also heard statements from developers that they think that hidden HTML fields in forms sent to the user's browser can be trusted because users don't see them and can't edit them, that speaking a proprietary protocol (without any additional security) is safe because nobody else knows the protocol, and that XSS is not really a vulnerability because all of the code is run on the client.

Some of these statements come from young programmers (back to the lack of proper college education) but many of them have come from much more seasoned developers (they, at least, have the sense to listen to me before passionately arguing their incorrect viewpoint).

Let us also remember that new types of vulnerabilities are being discovered all of the time and some of them have less-than-obvious exploits and non-trivial coding solutions. How to exploit an XSS vulnerability is perhaps not obvious but one could argue that good input processing, whether or not you are aware of XSS, is a requirement. That being said, without having been taught about HTTP response splitting would you expect even the most talented programmers to prevent it? I don't think I would.

So, IMO, not only do secure programming practices have to be taught, those teachings need to be kept up-to-date or they become useless.

I not only think a certification is a good idea. I think that there should be re-certifications. Perhaps those don't need to be as intensive as the initial certification but somehow you need to ensure that a certified person is keeping up with the newest trends in hacking.

- Neil
http://www.smithline.net

As someone intimately familiar with the loveliness that is No Child Left Behind, let me assure you that few things rankle feathers more than the concept of "aptitude testing." It's even more pernicious when there is talk of "consequences" associated with low scores. While I think NCLB is a generally bad program, that's not because it involves testing. Testing is an essential component of any system. I ask detractors what happens when they go to the doctor (once you get past the insurance and waiting around). Someone "check your vitals," then you describe the issues at hand. If the symptoms aren't sufficiently indicative, the doctor usually says "let's run a few tests." So, testing is necessary for diagnosis. Good testing can result in better diagnosis.

My problem with any "testing" initiative is that it's often seen as an end. The cycle isn't complete without the diagnosis, and if warranted, treatment stages. Testing can point out deficiencies (or even strengths) and serve as ONE USEFUL SET OF DATA upon which to base a number of decisions. And, yes, one of those decisions could be to let programmers who perform poorly seek other employment. Can't shuck fast enough, you can't make it as a corn shucker!

Identifying the current security concerns on an ongoing basis and challenging programmers to review and understand them has to be a good thing. Expecting management to identify which programmers are slow because they implement security and which are fast because they don't will require management that "gets it", so good luck with that. Another consideration is that better security also delays the day when government is persuaded that all programmers and all code must be certified in some all-inclusive manner that will forever eliminate all bugs in code. We already have ex-government security czars advocating that now.

I have often wondered what enforcement action is taken against those hackers, especially the ones who steal identities or actual cash frauds. It doesn't seem to be widely reported. Perhaps there is little success in this area.

My company provides Security Training services with a focus on Secure Programming. Our list of courses includes:

- Designing Secure Systems
- C/C++ Programming Security
- Secure .NET Development
- Java Development for Secure Systems
- Secure Java Web Services
- Cryptography
- Web Application Security
- Testing for Security

Anyone interested can find more information at:

http://www.skillbridgetraining.com/Catalog/course_view.cfm?SubCategoryID=138

You can also email me directly at:

SLeventhal@SkillBridgeTraining.com

Regards,

Steve