Jim
Just my $.02, I'm sure others will give more details.
Typically the same way you would any english based site. The Javascript is just javascript and in the case of SQL Injection everyone uses SQL-92 commands which are english-ish so the attack works pretty much the same. If you need to send part of the JavaScrpt in a Unicode character that's no problem either. The challenge I have had, especially on non-latin based languages, is understanding if my attack is working or not. Some times the error message you get back are a challenge to read but that's my not knowing the other language not an issue with the hack.
Programming languages are english-ish (not technical term but you get the picture) for better or worse so there isn't a Japanese JavaScript there is just JavaScript.
Dennis.Hurst at HP.com<mailto:Dennis.Hurst at HP.com>
________________________________
From: Jim Weiler [mailto:crispusatticks at yahoo.com]
Sent: Wednesday, 23 April, 2008 7:43 PM
To: websecurity at webappsec.org
Subject: [WEB SECURITY] XSS, SQL injection vulns on non-English sites
Q1. How would a cross site scripting vulnerability be exploited on a non english web site? Would a link containing a cross site scripting exploit for that site have to contain ASCII javascript or javascript characters encoded in some characterset that included the ASCII characters?
Q2. how would you do SQL injection to a non english web site, say japanese or arabic? doesn't the database engine expect ASCII SQL characters? If the web server says it understands UTF-8 I guess you could use a proxy to inject UTF-8 encoded ASCII SQL as form or URL parameter values.
---------------------------------------------------------------------------- Join us on IRC: irc.freenode.net #webappsec Have a question? Search The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/ Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20080423/84df5b48/attachment.html>