To prevent this kind of injection attack, I would validate the user input
and disallow the offending characters.  If you were not using it in a
hyperlink, I would suggest HTML Encoding it, as that would prevent the HTML
injection, but that doesn't help with the ampersand, and the search page
would need to HTML Unencode it or it would affect the search results.  If
you cannot disallow the offending characters, then you will need some way to
change the ampersand on your querystring so that it is not an ampersand but
can be interpreted by the search page correctly.

Hope this helps.

If this is an ASP.NET application, you can take advantage of the UrlEncode
and HtmlEncode methods of the System.Web.HttpServerUtilityClass.  Some
methods of some ASP.NET controls will HTML-encode for you, but the
System.Web.UI.WebControls.HyperLink control doesn't.  Assuming you are using
the HyperLink control to display the link, you should URL-encode the hobby
value and HTML-encode the display text.  e.g. (assuming that you've already
verified that the hobbyName string is not null):

yourHyperLink.NavigateUrl = "http://www.domain.com/search.aspx?hobby=" +
Server.UrlEncode(hobbyName);
yourHyperLink.Text = Server.HtmlEncode(hobbyName);

In the search page, you can simply read the value from the query string
items collection since it will already have been URL-decoded by the
underlying .NET objects.  e.g.:

hobbyName = Request.QueryString["hobby"];

Of course, if you are going to display this value to the user in the search
page, you should URL- or HTML-encode it, as appropriate.

Also, you should keep in mind that, while validation of the user-provided
values is certainly a good idea, it is highly unlikely to eliminate all
display problems (particularly those involving client-side encoding of
non-low ASCII characters) unless it is sufficiently strict to potentially
interfere with intended functionality.  Even if your initial validation
screens out all characters that could potentially interfere with HTML
rendering or functionality, later changes may re-introduce the acceptance of
such characters, and this will cause problems unless the application can
accomodate them via appropriate render-time encoding.  In addition, the web
user interface is rarely the only mechanism via which data can be provided
(e.g.: direct entry into the underlying db or files is usually possible),
and your code should probably accomodate even innocent mistakes at that
level.

HTH,
Nicole