|
Suckerfish sticky drop down issues in IE7 |
||||||||
Most people are familiar with the suckerfish style drop down menus, but as a quick recap they are lightweight CSS driven dropdown menus.
I won't go into massive depth here, but suffice it to say that there have been many improvements to the way they work, and the most streamlined version I've come across is here:
http://www.htmldog.com/articles/suckerfish/dropdowns/
It's a good article on how to get them working on your site, and how they interact with different browser versions.
What is quite interesting though is that there is an issue with them in IE7. If you use the 'sticky' version of them (where the menu stays visible even after mouse out) then IE7 has a CSS flaw in the handling of it.
As the link under here explains, there is a fix for earlier IE versions that creates a pseudo class to get them to work as they should, but IE7 handily circumvents this to break.
http://css-class.com/articles/explorer/sticky/
This entry details how to fix the IE7 bug and end out with a totally cross browser CSS friendly version.
|
Web safe color chart |
||||||||
Everyone needs a 256 bit 'web safe' color chart. Its sort of compulsory.
So here is mine. (Click for full sized version.)
|
Weird character encoding in eclipse - non Cp1252 |
||||||||
I've recently tried to import some source from Gmail, and save it as a text file in Eclipse, but discovered an encoding issue that seemed strangely undocumented online.
When I was trying to save the imported source, I would receive an error message:
"Some characters cannot be mapped using 'Cp1252' character encoding".
It turns out that Gmail is using a wider spread of encoding than usual websites. Simply click on File-> Properties -> Text File Encoding -> and select another encoding format until you hit the right one. In my case it was UTF-8.
Then eclipse will save it!
|
Cross Site scripting hack test form |
||||||||
One of the more basic cross site scripting hacks is where the user simply 'injects' other web templates into yours, using a form.
By submitting a string through a form and allowing it to return the value in an unencoded format a user can inject malicious code. In this example we will create a frameset, and set the source as a different domain than the originating site.
To test this yourself create a simply form, and set the value of the text field to the value that the user enters.
2
3<form method="post">
4
5<input type="text" name="formValue" size="30" value="<cfoutput>#form.formValue#</cfoutput>">
6<input type="submit" name="Action" value="Send">
7
8</form>
I'm using ColdFusion, but the language itself doesn't matter, the vulnerability is the same. Next submit the form using a string like the one below. This string is built up of the form field name, and a valid html frameset, surrounded by escape characters.
Submit the form, and you will be returned to the same template, but it has translated the html string, and is now proudly displaying someone else's site on your domain.
This is only possible because the form is returning the form value in raw html. You can eliminate this issue by simply adding a html stripping routine to the form. Something like HTMLCodeFormat replaces special characters in a string with their HTML-escaped equivalents.
