AJAX without the AX

28th Jul 2008 ¥åßßå

Javascript is still required

As a follow on from something I mentioned in this post ( Creating Tag Clouds? The nuts and bolts... ) I thought I'd share a method of achieving the "AJAX effect", without the AX bit. For those of you who don't know AJAX stands for Asynchronous Javascript And XML, you can find a full description of what it is and how it works on wikipedia ( wikipedia : Ajax (programming) ). However, there is another way to achieve the same effect without using the XMLHttp Request method ( wikipedia : XMLHttpRequest ) which has the advantage that it's able to make cross-(sub)domain requests, which is impossible to do with AJAX, and something that we require for version 3 of our blog software ( b2evolution ) so that it can still fulfil it's "multi-domain" aspect and we can add all the fancy bells and whistles that are in the pipeline as several of these need the ability to communicate with admin which can easily be on a separate (sub)domain from the frontend.

How does it work?

Creating a request is pretty simple, you just add a <script> tag to the pages <body> pointing to the url of your choice. This url can be on any (sub)domain you like as there are no cross-domain restrictions. In the example below the scripts "answer" is going to be pulled from my own blogs url ( innervisions.org.uk ) to show you that it really does work across domains ;) The url can also contain any $_GET ( php.net : $_GET ) variables that you like. This leads us to the 2 limitations of this method :

  1. The request can only use $_GET
  2. The response must be a javascript response ( see example below )

Once the request hits the server it can do whatever it likes with the variables passed and then "reply" to the requesting page by imitating a javascript file. This basically means that it has to set the correct headers and reply using normal javascript syntax. It's not as hard as it sounds.

Example code

To show you how it works we'll do a really easy example that takes the text typed into a box, sends it to the server which will reverse it and send it back to the calling page. The code on the calling page looks like this :

Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-UK" lang="en-UK">
<head>
<title>test</title>
</head>
<body>
<label for="theText">Type in the text to be reversed : <input type="text" name="theText" id="theText" /></label> <button onclick="reverseMe();">Reverse</button>
<script type="text/javascript">
 
function reverseMe()
{
  var theText = document.getElementById( 'theText' ).value; // grab the text
  var the_call = document.createElement( 'script' ); // create script element
  the_call.src = 'http://innervisions.org.uk/nonAjax.php?theString='+theText; // set the url
  the_call.type = 'text/javascript'; // to be sure to be sure
  document.body.appendChild( the_call ); // add script to body and let browser do the rest
}
 
function serversReply( theAnswer )
{
  window.alert( 'The server said : '+theAnswer ); // stun the crowd with a reply from the server
}
</script>
</body>
</html>

The code for the page being called looks like this ( note : it's very basic and it can be "broken", but it's just for example huh? ;) ) :

PHP:

<?php
$theText = ( empty( $_GET['theString' ] ) ? '' : $_GET['theString'] ); // grab the text to be reversed
if( $theText )
{ // we have some text, reverse it
    $theAnswer = strrev( $theText );// reverse the text
}
else
{ // we don't have any text
    $theAnswer = 'Gimme summat to do!'; // inform the user we're bored
}
$theAnswer = str_replace( "'", "\'", $theAnswer ); // single quotes would break the reply
header( 'Content-Type: text/javascript' );// set the correct mime type
echo 'serversReply( \''.$theAnswer.'\');';// trigger the function on the calling page
?>

So, does it work?

Try it for yourself ;)

Please note : comments for this post are disabled, any questions/comments/gripes/spam should be directed to this thread on html forums ( Html forums : Ajax without the Ax )

¥

 
 
 
 
37582 views · leave a comment

XSS should you care?

7th Jan 2007 ¥åßßå

Paranoia has its place

XSS is one of those geeky terms that you see floating round the net, usually accompanied by some innocuous example where they point you at a link to a 3rd party website and make a javascript alert() pop up saying 'XSS!'....... not very impressive huh? I mean, what use is a simple alert()? It couldn't possibly harm your website right?

WRONG!!!!! That innocuous little box is one of the worst thing that you could see on your site, especially if you have any form of membership, customers or database. If you see that then it means that you've just unlocked your door and left it wide open. It means that you've just failed misserably at the most basic rules of coding. NEVER TRUST INPUT and NEVER OUTPUT UNSANITISED INPUT

Connection details

Host: everyones

Username: muppet

Password: available

Now we all know, or we should all know, that you should never just shove information straight from $_GET/POST into a database ... hell, it's one of the quickest ways to unlock your database to the world, you might as well just put your connection details on your front page in <h1> tags. The very least you should do is escape the string, but that really isn't enough. Every single piece of data that your website uses should be verified against the type and contents that it allows. If you're asking for an ID make sure it's a number (sounds obvious, but you'd be amazed). Asking for a date? Either make sure she's hot or check the input is actually a date huh? A string? Only allow the characters you expect (and still escape it :|). However, you shouldn't just be doing this if you're going to shove the data into a database, you should always do it, even if you're only echoing the values to the screen

Still unsure what that little box means? How about if instead of the box popping up the link called a malicious javascript file? What could happen then? For starters all of your cookies are available to the javascript, so if you're daft enough to store a username/password in them then it's just been hijacked, and if you're the admin that means the code now knows your login for the site and it's VERY simple for it to “call home” and pass these details on. Or it could incorporate a keylogger and watch everything you do ... pretty scary if you're entering your credit card details huh?

“ Yeah, but I never store the actual details in the cookies, I encrypt them! ” ..... that's really great ..... unfortunately as far as your code is concerned the javascript is your user and can easily make requests on that users behalf, either with something as simple as an image call or full blown ajax requests .... either way you're still screwed.

“ Yeah, but it only happens to crap coders who write shitty little websites that no one will use right? ” ..... urm, guess again ..... I spent the the last few days trawling round the web reading up on this and eventually ended up on this thread on sla.ckers.org which has a list full of some of the biggest names on the web, including several .gov websites! At the time the thread was 34 pages long and growing daily.

“ Yeah, but I filter out javascript from all inputs! ” ..... excellent ..... so did myspace.com and they got brought to their knees by the Sammy worm which was written in javascript.

Now, the boys at b2evolution are pretty hot when it comes to sanitising input and output, but that only works if you use their functions ( param() is there for a reason ;) ) and if you code a plugin/hack that doesn't use them then you really need to make damn sure that you do your own checks/sanitisation. This is especially true if you're going to make your plugin a public release because then it's not just your blog that you've unlocked the door of, it's every blog that installs your plugin/hack.

If you want to read more about this then try some of the following links, there's a good deal of information about this and other security problems, including ways of blocking these holes :-
Full Disclosure - sla.ckers.org (highly recomended if you like horror stories)
PHP and Web Application Security - shiflett.org
Nitesh Dhanjani - dhanjani.com
PHP: Security - Manual - php.net

The moral of this story is very simple “ In God you trust ... just sanitise His input first ” ;)

If anyone from sla.ckers.org happens to read this post, I'd like to thank you for your full disclosure forum. It certainly was an eyeopener!

¥

 
Tags: coding, security
 
 
 
16512 views · leave a comment

So, you think you're a webmaster?

9th Feb 2006 ¥åßßå

Introduction

I'd like to touch upon the subject of attitudes and methods, when it comes to coding, that are rife amongst amateur coders ... usually the sort that call themselves a "webmaster". They get on the big wide web, and it's full of bells and whistles and new toys, and they just want to have them all. So they produce a website using tables (when it'd be far easier and bandwidth friendly to use divs), they have flash buttons (to achieve a rollover effect that could be achieved with css), they use javascript effects (quite a few of which can be reproduced with just css), they also tend to produce fixed width sites (because they're easier) and usually their site only works in IE6 (although a few hours with a validator could cure most of that).

Ok, I might sound like a bitch, but let me tell you why I find all of the above appalling.

The WWW

One of the main aspects of the web is the WW bit, it stands for "Word Wide" (yeah, yeah, I know you know). What that actually means is, it's available to anyone and everyone in the world (allow me a rose tinted glasses moment) and is controlled and owned by nobody. This means that even a blind man in outer mongolia has the right to expect to browse the internet as freely and easily as anybody else (this is what WAI/508 is all about) ...... lets follow him as he hits a "webmasters" site using a text reader :-

  1. Every image is replaced by the alt text ..... if only they'd included some
  2. Every bit of CSS fails, but that's alright because they haven't discovered CSS yet.
  3. Every bit of javascript on the page fails, so, there go all the special effects, but, more importantly, there goes all of the content that they controlled.
  4. Every bit of flash fails, so there goes all the site navigation, now we're limited to just one page .... and half of that dissapeared with the javascript failing.
  5. All of the nested tables used make the poor text reader work like a demon trying to understand what follows what, now all of the remaining content is starting to sound jibberish, and you can't navigate to another page because the navigation failed with the flash.

So, until the web has a damn sight less "webmasters" and more coders who actually give a shit about the visitor being able to browse through their site no matter what their abilities or needs, I'm afraid it's been reduced to just plain "Web". Of course, the "webmaster" couldn't care less, his stats show that 98% of his visitors are using IE6 with javascript enabled and flash installed ....... they never think to ask "why ?".

What do I know?

I say all this from experience, my first website was a pure javascript controlled monstrosity that only worked in IE (mind you my stats showed me that all my visitors used IE with js enabled), and even though I converted it to be cross-browser compliant it still requires javascript !! I've spent the last 12 months, on and off, recoding my website, and the next version only uses javascript to enhance a visit, if it's enabled, and to still be fully functional with as many bells and whistles as possible, even in a text reader ...... although the galleries will be a tad tough to see in a text reader.

So, if you're a webmaster and you happen to be reading this, here's what I recomend:-

  1. Your website should work with css, flash, javascript turned off.
  2. Your website should not make use of excessive tables for layouts.
  3. Your website should validate for both (x)html and css and, ideally, WAI/508 (this now becoming a legal requirement in several countries, especially for any websites that have anything to do with the government).
  4. Your website should work in all major browsers.
  5. Your website should work at all screen resolutions.

Of course, you don't have to listen to anything that I've said in this post, you have the right to close your browser and carry on being a webmaster ..... just don't be suprised when I visit your site and I close my browser because I'm using FireFox with flash disabled (and frequently with javascript disabled) and I browse at 1280 x 1024 ...... but your stats will still show you that 98% of your visitors use IE6 with javascript enabled and flash installed, so that's not a problem right?

¥

 
Tags: css, validation, webmaster, xhtml
 
 
 
20410 views · leave a comment
 

Categories

 
 

Archives

 
 

Recent comments