SEO Crusade News http://www.seocrusade.com/news/ SEO Crusade Industry News en-us Nucleus CMS v3.23 © Weblog http://backend.userland.com/rss http://www.seocrusade.com/news//nucleus/nucleus2.gif SEO Crusade News http://www.seocrusade.com/news/ Google release CSE http://www.seocrusade.com/news/index.php?itemid=46
By example, before CSE you could only display pages from your own web site. Now you can display pages from any web sites you want. You can also order these web sites so your web site/partners web site comes top.

The beauty of this is that if a search is not going to give a result from your own web site, then your results will always give some sort of result.

On top of this, you can either have the results displayed by Google, or you can include the results on your web site within an IFrame.

Benefits: -
You can customize the look of the results displayed
You can order the results to force certain URLs to the top of the results
You can filter results out by expression or by url
You dont need a crawler for your own web site

Drawbacks:-
If you are a profit organisation, then you have to display Ads with the results
The results aren't going to help your rankings in Google because Google provided the listings in the first place

So, at first glance the benefits outway the cons. This is a great move by Google and will help them to capture more of the vertical search market.

If you want to read more about CSE then check out Matt Cutt's blog at http://www.mattcutts.com/blog/review-custom-search-engine/

If you want to use the product then go to http://www.google.com/coop/cse/ and sign-up. Ok. you'll need to have those all important web skills, but its pretty straight forward.

If any of you out there have used it, please leave your comments so other people can see what its like.]]> Development http://www.seocrusade.com/news/index.php?itemid=46 Fri, 27 Oct 2006 16:25:45 +0100 AJAX Security http://www.seocrusade.com/news/index.php?itemid=24 Asynchronous Javascript And Xml Security
AJAX is becoming more popular as the web demands seamless use, although security issues come to the forefront as a result.

Security should always be at the forefront of any web application. Especially when databases containing user information are concerned. Whilst AJAX is delivering some of the best interactive web experiences in years, security between client and server now becomes an issue.

Ajax essentially can produce many threads of communication between the client and the server at the same time. One click on an AJAX enabled web page could produce any number of communication threads to the server from the client.

With the use of PHP, AJAXcan be implemented in a more secure fashion, although planning is still the most vital aspect to developing any secure AJAX web application (as well as testing of course).

Producing Secure AJAX PHP web applications simply


One of the simplest methods of securing AJAX altogether is to use SSL certificates on your web server. Once you have a secure web server configuration, implement session cookies within your PHP script(s) and validate the session every time an AJAX request is made. Then ensure all of your AJAX requests are passed to the secure server (https://).

With SSL certificates any information passed between the client (web browser) and the server (web server) is encrypted and, it has been claimed, cannot be broken once the SSL connection is established. Another alternative SSL provider is CACERT. They provide free SSL certificates to community.

The problem with this is scalability. What if you are a small business and don’t have the resources to employ an SSL capable web server, the technical ability to implement SSL correctly or the cash to purchase these services? Well at this stage of the game you will be stuck if you want to implement AJAX on your web site with a near to nothing budget.

This doesn’t help the uptake of AJAX for web applications and is already slowing the deployment of AJAX to the majority of web sites. It is surprising how many web sites out there are still stuck in the 90’s.

Why AJAX? The reason for AJAX’s increased deployment is the advent of web2.0. With web2.0 your web site is supposed to be conversant and highly interactive. This is not just a fad of the techies within web development, but realised directly as a result of people using the web. People visiting your web site now expect to be entertained and involved. Even the most boring of web sites can now provide interaction for the site visitor. Like predictive text on a mobile phone, Google have Google Suggest (http://www.google.com/webhp?complete=1&hl=en), just one example of an interactive web 2.0 application.

Producing Secure AJAX PHP web applications thoroughly


Ok, so implementation of SSL and Sessions can greatly improve your AJAXsecurity, but you can go even further.

Even if you don’t have SSL certificates, you can improve your AJAX security with PHP by hashing your communication strings between AJAX and the SERVER. Using a hash algorithm you can produce a system similar to SSL, without doing all the server stuff. Although recommendations still remain with obtaining a SSL certificate for your web application.

All data between the client and the server can be serialised using a proprietary hash algorithm. With the additional use of Sessions within PHP you can then start to see how robust this type of solution can become.

For information about producing your own hash algorithms check out the phpclass “class hash crypt” on http://www.phpclasses.org/browse/package/2982.html.

Continuing with hashing strings; when a client starts a session, distribute a unique key to the client and store that key on the server. The client-side script can then include this key in the hash algorithm and serialise the communication. The server would then pick up the communication, check the session exists, unpack the communication using the privately stored key and then read the data.

These keys can then be changed as each request is made. One concern with this method is that as AJAX is based on asynchronous communication, several threads of communication could be started at once. Changing the key like the above example would fail. If the client did not receive the amended key prior to sending the next/concurrent thread, then the server API would not be able to unpack the data. Unless the client waited until the server responded to each request, therefore updating the key prior to re-communicating. There are still problems here too. The list of problems with AJAX security goes on and on.

Here are a few pointers for developing AJAX and PHP: -
1) Never use GET when communicating between client & server.
2) Session data is transmitted from the client every time a request to the server is made. Therefore, without SSL your session cookie data is visible if sniffed.
3) Requests by the XmlHttpRequest object can only be made to the originating server. Although don’t forget to do the server checks anyway. Some people also claim that XSS (Cross Site Scripting) is possible using XmlHttpRequest.
4) Do as much authentication on the server side as possible without deprecating performance. Check all the obvious, e.g. user agent is still the same.
5) Instruct the client to place certain information in the header of the XmlHttpRequest and see if the requests to the server match or not.
6) Mission critical, personal or business related data should be kept outside of the AJAX loop unless you are 100% certain there are no security flaws.

As AJAX has been around for some time now, there has been significant development into making AJAX secure. Although holes are still being found.

The following are a couple of resources relating to technology that could help when developing a secure AJAX web application.
Description and Examples of JSON - http://en.wikipedia.org/wiki/JSON
Home Page of XOAD - http://wiki.xoad.org/index.php?title=Wiki_Home
Download Page of XOAD - http://wiki.xoad.org/index.php?title=Download
Home Page of SAJA - http://saja.sourceforge.net/
Download Page of SAJA - http://sourceforge.net/project/showfiles.php?group_id=156741

Checking your AJAX security


One of the most expensive aspects when developing a secure web application might be security.

If you are developing a web application that stores personal, business or mission critical information, then you no doubt need to provide security.

Security should be at the forefront of any project that has any of the above elements and if you are employing AJAX technology, then your security budget may just have to treble.

Even if you have developed your AJAX application and are pretty certain of its integrity and security, it would be well worth checking it.

Denimgroup have released a product for the .NET platform called Sprajax that has been published open source and can be downloaded from http://www.denimgroup.com/Sprajax/Default.aspx. The only downfall for Sprajax is that it is platform dependant (.NET). Hopefully a cross platform (PHP) version will be available soon.

It is helpful to follow some of the security companies too, as they are mostly at the forefront of these issues and some of them release their findings to the general public.

The http://www.webappsec.org/ is a great resource, although it is difficult for a novice to identify bugs found in AJAX and other web apps. Rather technical too.

CNET is a great worldwide resource at
http://news.com.com/The+security+risk+in+Web+2.0/2100-1002_3-6099228.html

And of course, keep your eyes on this post too.]]> Development http://www.seocrusade.com/news/index.php?itemid=24 Thu, 31 Aug 2006 17:29:25 +0100 Using SERVER variables in PHP http://www.seocrusade.com/news/index.php?itemid=8
Ok, theres a question: -
Q: Whats the difference between a relative link and an absolute link?
A: An absolute link will include the whole path to the object (http://www.seocrusade.com/marketing). Whereas a relative link will only include the necessary path info to the object (../marketing).

Right. So now we have established the difference between relative and absolute, the problem you may face is that by using absolute links, you will not be able to move your code between domains without changing the absolute links....

For example, you have a website hosted on www.domaina.com and want to move it to www.domainb.com, but all the link are written http://www.domaina.com in the code. Rather than doing a find and replace on all your domaina to domainb, write your code using $_SERVER['HTTP_HOST']!

for example http:.

Ok, so you may (should) be doing this anyway, but if you're not and your dynamic code is categorised by directory structure, then this is the answer.

Your code can then move from domaina to domainb without any code changes. This only works if your code is categorised by directory structure and not all within the one page.]]> Development http://www.seocrusade.com/news/index.php?itemid=8 Tue, 22 Aug 2006 17:39:51 +0100