Jonathan Rockway (j...@jrock.us)

FWIW, this is the sort of message you'd get if you typo'd the filename
of your database.

Regards,
Jonathan Rockway

BTW, I have to mention one of Andy's talks at OSCON:

http://en.oreilly.com/oscon2008/public/schedule/detail/3001

It's called "People for Geeks", i.e. "how to be nice to people".

If it's possible to die from an irony attack, you might not be seeing
much more of me :)

Regards,
Jonathan Rockway

* On Wed, Oct 01 2008, Moritz Onken wrote:
> I imagine a case where the attacker's site opens a iframe to your
> site which exploits a XSS issue and can send the hole form
> information back to the attacker's site. He has now the HMAC and
> the random string.

I was under the impression that you could open an iframe to someone
else's site and manipulate it from javascript running on your own site,
without relying on any vulnerabilities on that site.  Maybe not?  Maybe
flash can do this?  (Why do we even have iframes?  For serving ads?)

Anyway, Template::Refine is a great module for adding stuff to forms, in
the event that your form builder isn't already adding some sort of
unique token.  I actually use it to add the "name" field to all the
inputs; at some point I will just "encrypt" these like Seaside and many
other frameworks do.  You can then validate these with an ActionClass.

Regards,
Jonathan Rockway

A simplified version:

1) Identify sources of input to your application

2) Ensure that you called Encode::decode('the-character-encoding', ...)
on all that data.  If you are dealing with pure ASCII, I guess you can
skip this step.  Encode::decode('us-ascii', ...) probably works though.

Sometimes libraries will do this for you, but don't count on it, verify
it.  If you don't see the code doing it, it's not being done.

Note that the existence of the "UTF-8 flag" does not tell you whether
this is being correctly done.  Your program can be perfectly
Unicode-clean and never have a string with the UTF-8 flag on.

If you see stuff like utf8::encode and utf8::decode or Encode::_utf8_on
and so on, your program is horribly broken.  Use Encode properly before
continuing.

Finally, keep in mind that there are odd sources of data.  Hash keys
from config files, file names, file extended attributes, form params,
form field names, URIs(*), etc.

(*) handle these manually, there is no mention of Unicode in the URI
standard.

Some people do things like put Japanese text in the HTTP headers.  This
is not allowed.  ASCII only.

3) Identify where you output text.

4) Ensure that you called Encode::encode('output-character-encoding', ...) on
any data that leaves your program.

In the case of dealing with external applications, make sure that you've
told them what the output character encoding is.  Databases have flags
for this, HTTP has the Content-type header, etc.

5) You're done.

I have found that Devel::StringInfo is very helpful; you can have it
dump the information when you are inputting data... it will make it
clear when you have bytes instead of characters.

Be sure to test with all sorts of input -- I always use characters from
ASCII ("foo"), Latin ("?"), and Japanese ("??").  If your app gets
those three right, it is probably OK.

Regards,
Jonathan Rockway

You're unbanned now.  In the future, just /msg an op (usually mst) and
they will take care of it (especially if it's because your client
malfunctioned).

Regards,
Jonathan Rockway