MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld) [LWN.net]

MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

Posted Mar 15, 2008 8:17 UTC (Sat) by jschrod (subscriber, #1646)
In reply to: MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld) by flewellyn
Parent article: MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

I know what I'm talking about; I have real-world experience in both. Please read before you
post: I did not compare the technologies, but the amount of security-related problems that
both are causing.

Currently, PHP applications make up the vast majority of security problems in the Web
applications area. The main root cause for that is that most programmers don't check the
user's input properly, leading to SQL injection, CLI attacks, or XSS problems.

AJAX has a similar problem that is not mitigated by the typical AJAX libraries like Prototype,
et.al. (ajax4jfs handles it partly, but is a PIA to use.) If one looks at most Open Source
programs using AJAX, the programmer seems to forget that AJAX means to widen the set of
server-side requests. I don't expect the closed-source programs to do better. They program as
if the server-part of an AJAX implementation could only be requested by the respective clients
and not by any arbitrary system on the net; they do no input checking at all. Thus, by feeding
unexpected input to AJAX requests opens a whole new bunch of attack vectors beyond the page
requests. That most AJAX tutorials and books don't emphasize that problem at all, doesn't make
it easier. The result? SQL injections, CLI attacks, XSS problems.

Since one widens an application's server request set with AJAX, one gets an enhanced set of
problems when the tool doesn't take care of the cowboy programmer's mindset ``I don't need no
input checking for special characters and don't need no output checking for HTML characters.''
That's why AJAX introduces even more security problems as the most prevalent
security-problem-causing Web technology today, PHP. That has nothing to do at all with the
fact that they are different technologies.

Concerning my further statement that programing AJAX is a nightmare: Just make the browser's
Back button work in any AJAX-using Web application. 'Nuff said.

(Log in to post comments)

MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

Posted Mar 15, 2008 14:06 UTC (Sat) by Los__D (subscriber, #15263) [Link]

If you have any part of the security or escaping/checking in the AJAX or Flash layer, you have
much bigger problems than the browser part chosen.

AJAX CAN NOT make your application more or less secure.

MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

Posted Mar 15, 2008 14:36 UTC (Sat) by jschrod (subscriber, #1646) [Link]

Sorry, but I can neither parse your post, nor do understand what you want to tell me.

First, there seems to be a verb or an adjective missing in your first sentence part before the
comma. I shall have what? For the sake of discussion, I assume the `AJAX layer' is `broken' or
`wrong' or some similar. I also assume that you mean the server-side of AJAX programming with
`AJAX layer' in that sentence.

Then, I don't understand what you mean with the ``browser part''. The browser has not played
any role in this discussion sub-thread up to now.
If you want to say that server-side problems are bigger than browser-side problems, we are in
full agreement. I did never said otherwise. I said that there *are* many applications with
server-side problems. One needs only to look at the SANS security mailing or at any
vulnerability disclosure mailing list, loads of Web applications with server-side problems are
out there.

That said, I differ that AJAX doesn't change anything here. AJAX radically enlarges the number
of server requests that an application has to realize. Alone with that enlargement, the risk
of programming errors is enlarged. In addition, these additional requests are often not
properly integrated into Web application frameworks. Take Java Server Faces, for example:
There you have input conversion and validation as part of the framework. I.e., they are done
automatically. Enter AJAX, and that part is either not there any more, one has to program
process listener classes and do the validation manually or one has to use ajax4jsf (which is
very complicated to get right). Similar problems exist for other frameworks like Struts or
Tapestry.

Of course, if would be nice if any programer would completely validate any input he receives
and realizes these checks without any errors. But in the world where I'm living, and this is
also the world that is reported about by SANS and all security mailing lists, this does not
happen, though. In my world, framework support for *automatic* input validation / output
checking is extremely important to get better security into Web applications.

Therefore, I differ with your last statement: AJAX CAN make your application less secure:
Since many (popular) Web application development frameworks don't automatically support
server-side conversion and validation of AJAX requests' input parameters, programers have to
realize them by hand. And that is more error-prone, thus creates a higher risk and thereby
lowers the application's security.

MIX - Novell's de Icaza criticizes Microsoft patent deal (LinuxWorld)

Posted Mar 16, 2008 6:56 UTC (Sun) by flewellyn (subscriber, #5047) [Link]

I'll give you this part: lack of proper input validation does cause a lot of security problems
for web applications.  But I think it's a mistake to blame PHP, AJAX, or whatever language or
technology, for the prevalence of those issues.  It's certainly easy enough to write a CGI
program which has a SQL injection or CLI vulnerability, and anything using Javascript can have
XSS problems if you don't validate input.

Secure programming is hard whatever the platform.  I will grant you this much: the fact that
AJAX exposes more of an attack "surface" than traditional web programs means that you have to
consider the server-side AJAX functions as the security "boundary", and validate input there
as well as on the client-side.  It doesn't mean that you can't do secure AJAX programming,
though.

As for the back-button issue, well, I have seen this done.  Depending on the application, this
may or may not be desireable anyway.