And it never was.
In the original article about Ajax, the author states:
Although he never calls it an acronym and never uses it as such, this particular statement can be blamed for the widespread misconception that Ajax is an acronym. Microsoft even thinks it's written as AJAX. Thankfully, most books get it right.
The assertion that it's AJAX reminds me of similar assertions that Perl is PERL. If you have some extra time, read this debate from a few years ago; it's entertaining.
In my talk Tuesday night at New York PHP, I tried to provide a concise and precise definition of Ajax as I interpret it:
Client-side technologies / techniques that allow two-way communication between the client and the server.
I want to include all of the creative client-side techniques used to communicate with the server (e.g., IFrames) without including the purely client-side techniques that don't interact with the server and therefore aren't Ajax at all.
I think my simplistic definition might still be too restrictive, though. In the case of something like Netflix's star rating, the goal is just to send the rating to the server. You can update the interface with CSS, so two-way communication isn't necessary. You could argue that the use of
<script src=""> doesn't really constitute two-way communication either. I'm sure there are other examples.
How do you define Ajax?
I'm proud to welcome Luke Welling to OmniTI. Luke is a prominent member of the open source community, probably best known as the co-author (along with Laura) of one of the best selling open source books of all time, PHP and MySQL Web Development. Those who know him are more familiar with his keen sense of humor and undying urge to bait people for his own amusement.
He is working with me as part of our growing web application security practice, focusing on three key areas:
- Security Training Program
- Help clients avoid security problems. (Teach a man to fish.)
- White Box (Inside) Security Assessments
- Help clients identify security problems by thoroughly reviewing the source code.
- Black Box (Outside) Security Assessments
- Help clients identify security problems by actively testing the live application.
As George mentioned last year:
Web security is a relatively misunderstood field; many folks are looking for the silver bullet or one-shot fix that simply doesn't exist.
Our multi-faceted approach has been working very well, but like many others, we are continuously improving our techniques, tools, and expertise. No one can be sure to find every security problem in a web application, but with Luke's help, I think we can get closer than most.
We have some related projects in development that involve fun stuff like Sara's experimental extension, parsekit. I'll probably be blogging more about parsekit in the coming weeks.
Anurag Agarwal (whose blog is part of my planet) has been interviewing members of the web application security community for the past few weeks. As part of each interview, he has been providing a pretty thorough list of each person's contributions. The result is a big collection of web application security resources.
He has posted a reflection on me this week. It reminds me how behind I am on posting articles and hopefully gives me the kick I need to catch up. :-)
I'm honored to be considered among experts like Amit Klein, Robert Hansen, Jeremiah Grossman, Ivan Ristic, and others.
Thanks for the interview, Anurag!
There are a number of quality PHP and open source conferences each year. Here are a few that are taking place in the next month or two:
- 16 - 18 May
- Chicago, Illinois
- 18 - 19 May
- BraÅŸov, Romania
- 23 - 27 Jul
- Portland, Oregon
php|tek is being held in Chicago this year, and there are some exciting new social events to spice things up. I'll be giving a talk entitled PHP Security by Example, a brief hands-on tour of some of the most dangerous security problems. I'm also giving a talk entitled The Truth about Sessions, a detailed look at PHP sessions.
eLiberatica sounds like a really cool conference, not only because of the excellent lineup of speakers, but also because of the intriguing location. Where else can you learn about open source technologies in the shadow of Dracula's Castle? :-)
OSCON (O'Reilly Open Source Convention) has only recently selected talks, so there isn't much information available on their web site yet. I'll be giving an updated version of my Essential PHP Security tutorial as well as a talk entitled Security 2.0 that covers emerging trends in web application security.
Security researchers have found what they say is an entirely new kind of web-based attack, and it only targets the Ajax applications so beloved of the Web 2.0 movement.
Although the attack is not at all new, it is worth reading about if you're using Ajax and don't know what CSRF is. Jeremiah's Gmail exploit from early last year is a good example that uses CSRF for information disclosure, which is all this really is.
Being in the web application security profession myself, I appreciate the strong desire among my peers to increase awareness, but I'm not fond of the tendency to deliberately misinform people and incite fear based upon false pretenses. We should strive to offer clarity, not confusion. In this particular case, there are also some strong technical concerns to consider.
In some of the comments I've read in various places, people new to CSRF recommend checking the
Referer header as a safeguard. This does not offer sufficient protection against CSRF, because an attacker can forge HTTP headers with Flash.
I'm a bit late for CSS Naked Day, but since I finally have a blog that respects web standards, strives for accessibility, and produces logically-ordered markup, I decided to give it a go.
What is CSS Naked Day?
The idea behind this event is to promote Web Standards. Plain and simple. This includes proper use of (x)html, semantic markup, a good hierarchy structure, and of course, a good 'ol play on words. It's time to show off your <body>.
So, for the rest of the day, this site will be naked (sans CSS).