Agentless Backup is Not a Myth
Think about HTML for a minute. We don't really "view" web pages anymore. They're programs. We "run" them in our browser. Even a tiny fragment of HTML can contain a script. Even without JavaScript, web pages can be used for a Cross-Site Request Forgery (CSRF) attacks that perform a series of functions for the attacker. That's a kind of program too.
Would you open an HTML document sent to you?
Chain-gang attack
Attackers have now started to chain these attacks and use them in multiple stages. Consider the recent massive bot attacks that used SQL injection to jam JavaScript code into all the strings in a database. The infected data gets used in a web page and the attack redirects the victim's browser to a site that installs malware. You can imagine attacks that are passed from system to system before they are ever executed and their payload is realized.
One factor that makes detecting these attacks difficult is that the web enables so many different types of encoding. There are more than 100 different character encodings, and we've added higher level encodings such as percent-encoding, HTML-entity encoding, and bbcode on top of those.
The real nightmare here is that anywhere downstream, systems may decode this data and reawaken a dormant attack. So, even if your application isn't vulnerable to injection, someone might use the data from your application or service.
As Web 2.0 continues to mashup data from different sources, the likelihood of these attacks increases.
Stamp out injection
You should view untrusted data as though it's malicious code and treat it accordingly: validate, separate, and encode.
Validate: have a whitelist input validation rule for every input - no exceptions. Not just for form fields, but hidden fields, URL parameters, headers, cookies, and all backend systems.
Separate: don't mix up the data into command strings. Wherever possible, you should use parameterized interfaces, such as PreparedStatement in Java, that prevent injection by keeping code and data separate.
Encode: encode untrusted data for the destination. One thing you absolutely have to do, but almost nobody does, is specify the character set you'll be using. Then you'll need a set of methods that apply the proper encoding for the destination, such as an HTML page, HTML attribute, JavaScript, XPath query, LDAP query and so on.
Show you care
Injection is not a new problem - we've known about it for decades. The body of knowledge on XSS and SQL injection is extensive. If your system forwards an attack to an innocent victim, though, you not only make yourself look bad but in the Web 2.0 world there's a chance your software will lead to wider a proliferation of attacks than was possible in the bad old days.
Jeff Williams is the founder and CEO of Aspect Security and the volunteer chair of the Open Web Application Security Project. His latest project is the Enterprise Security API, a free and open set of foundational security building blocks for developers.
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
Minor correction...
When, in #3, I said "If you really MUST have an interactive website" I meant "If you really MUST have a website that is interactive without the traditional post-to-server, refresh page approach". Sorry about that.
Obviously everything's interactive these days; otherwise you wouldn't NEED server-side code. The problem with AJAX is that designers want websites to act like desktop applications, and vendors are lining up in agreement (because they want to rent you software as a service in perpetuity instead of sell you software once). My position is that it's all snake oil being foisted on you for selfish reasons and you're better off doing it the old way.
Sorry for being unclear.
Blame the *users*? Blame the USERS? Furrfu...
How is it the user's fault that "web developers" are, for the most part, incompetent knuckle-dragging buffoons. Should users be expected to retrieve and peruse the source (including all the scripts, stylesheets, embedded images, Flash videos, PDFs, QuickTime movies and all the other crap that gets embedded into HTML documents nowadays) for each page and identify whether there may be security issues with it before opening it in a browser? Is it really too much to ask to expect people who are (nominally at least) professional programmers to actually have at least the rudiments of a clue about the job?
I suggest banning Register readers from commenting until they can demonstrate how to comment sensibly (if ever).
Web 2.0 is a Mega Fail -- this whole SUBJECT is dumb.
Hear me out.
The whole subject of "keeping code and data separate" is dumb. It's pushed by so-called "web developers" who seem never to have actually studied computer science. Real programmers do their coding on the server side, using OOP languages, and they know enough to use parameterized statements so SQL injection isn't a problem. TOY programmers learn HTML and JavaScript and buy some square glasses and a turtleneck, then go about propagating the walking abortion that is Web 2.0.
Listen, you want to know how to do a proper website? It's easy. I've been doing it for over ten years. Try this on for size:
1) All code belongs on the server side. Use an OOP language like Java or C#. Ideally, you should separate out your database-touching code on an app server behind an extra firewall (you want at least 3 tiers, plus the user's browser). If you're a tiny shop on a hosting service, and all you've got is the web tier and a database, you've got to make do with that. Pick a hosting service that uses Unix, it's generally a little safer. Your server side code should accept the user's inputs, then validate them (don't forget that part!), formulate a response and send an assembled web page back to the browser. This means the browser only sees static pages, which makes it friendlier to a wide variety of browsers and screen readers (for the blind) as well.
2) The ONLY thing you should put in the browser is the U.I. If you put ANY code in your web pages, and you really shouldn't because not everyone has JavaScript turned on, you should only include that which is necessary for proper rendering of content, plus maybe a client-side pre-validator to save the user some time if he screws up a form-entry field. If you want to save state, keep it in a session object on the server side -- don't put it in the client, where it can be altered by the user. KEEP IT SIMPLE. Don't get fancy! You're not running a TV show, you're serving something useful to the user. Focus on what your user is trying to do, and make it as easy as possible for him. Don't make him think.
3) If you really MUST have an interactive website, like for example, if you're doing a movie ad, do it in Flash, and have it only display static data you've staged in the browser. Flash is ideal for MOVIES, and MUSIC and GAMES. For everything else it's a complete waste of time and it locks out the blind and people with alternative browsers so it's not very socially friendly.
4) Whenever someone in your office starts talking about Ajax or Web 2.0, BITCH SLAP HIM. Explain that it's for his own good and you're only trying to help, then ask him if the feeling has passed. If he hasn't been cured yet, repeat as necessary.
The web is a mature medium, with many established, safe practices. Try adhering to what's been proven to work, and stop trying to change everything every couple of years!
Seriously.
Paris because... Well... She's cute, isn't she?
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
