Ilia Alshanetsky’s profile

I believe other people have mentioned it before in various rev="canonical" articles, but I'll revisit the matter. In most cases URLs are generated automatically, it would be a trivial matter to simply crc32 the URL and make a hex value (8 chars long) representing it. When generating the link this is what would be used rather then this-is-my-really-verbose-title-for-something-or-rather. You could apply the same logic around any built-in local links via a regular expression.

As far as the rev="canonical" itself, I think it would be much better implemented via an HTTP header such as "X-Rev-Canonical" you've suggested as it would mean it could be obtained via a simple HEAD request without the need to having to parse the HTML code to extract it.

Posted in Save the Internet with rev="canonical".

Sun, 12 Apr 2009 at 21:07:02 GMT

I think allowing HTML is very dangerous and any "safe-HTML" is a step back, there will be ways to inject HTML/JavaScript through it. If not due to parser, but via a user of a browser supported syntax that does not meet the spec.

Consider things like

<block

quote> tag for example or embed \0 chars, etc...

Posted in Allowing HTML and Preventing XSS.

Wed, 14 Mar 2007 at 21:08:26 GMT

I think it is a matter on interpretation, I just asked a bunch of people and most "parsed" # as anchor. A few did seem to get a bit confused, however almost no one (one person did) recognized "fragment" which is what the addressing RFC calls it.

Given that the author tries to make things understandable as possible it only makes sense they'd use a more familiar name. IMHO.

Posted in Adobe PDF XSS Vulnerability.

Wed, 10 Jan 2007 at 22:17:59 GMT

Actually anchor is the correct name for #foobar according to the W3C specification.

http://www.w3.org/TR/html401/struct...s.html#h-12.2.1

Anchor specifically refers to #text bit. <A> is an element tag.

Posted in Adobe PDF XSS Vulnerability.

Wed, 10 Jan 2007 at 17:49:17 GMT

Actually it is possible to fake POST requests without the use of Ajax it is just far more complex and requires greater degree of social engineering. It is limited to IE only (<=IE 6, haven't tried with IE7), but given that it still commands vast majority of user-base it is good enough.

Posted in Ajax Security.

Tue, 12 Dec 2006 at 20:33:44 GMT

Isn't

echo "<ol class="code">\n"; and this as well echo " <li class="even">{$html['line']}</li>\n"

a parse error? :)

Also, instead of

while (strpos($code, "\n\n\n") !== FALSE) {

$code = str_replace("\n\n\n", "\n\n", $code);

}

could you not just do:

$code = preg_replace("!\n\n\n+!", "\n\n", $code); ?

Posted in Formatting and Highlighting PHP Code Listings.

Fri, 27 Oct 2006 at 00:36:55 GMT

I think when it comes to bug reporting, be it security or otherwise, you (as a developer) need to be careful not to put too many bariers to entry. Most people already fail to report bugs, by making it tough on the small percentage that does, especially tricky ones involving security, you risk alienating the few who do.

In my personal opion it is often better to have a red faced developer (or Company) rather then an unplugged security hole that is being actively abused by so called "blackhats". In my experience people often find every execuse to NOT fix security holes, until they get burnt badly, once or twice. After that they get on with the program so to speak, and if this process takes an occasional full disclosure, so be it.

In many cases people publish unfixed exploits because the vendor refuses to fix it or deploy a solution in a timely manner. So, the person who discovered the exploit publish in an attempt to accelerate fix deployment and warn users of the possible issue so that they can put intermediate workarounds.

Posted in Reporting Vulnerabilities.

Wed, 24 May 2006 at 02:53:18 GMT

So to summarize Andrew's points:

* Most programmers are inept.

* Languages should be designed to protect developers against themselves.

* Functionality is bad because people can't be trusted to use it.

* Simple is bad, because it allows people to write code without getting a PHD.

Posted in PHP Insecurity.

Mon, 23 Jan 2006 at 17:36:19 GMT

Not to downplay the vulnerability, but it is important to note that to make the exploit possible a multibyte character set needs to be used in MySQL. This is not the default configuration setting nor a common situation for most MySQL servers. So, while this exploit clearly demonstrates the need for the use of proper escaping function or better yet prepared statements, it is not something that would affect vast majority of LAMP systems.

Posted in addslashes() Versus mysql_real_escape_string().

Sun, 22 Jan 2006 at 17:03:08 GMT

Actually the problem is not limited to Internet Explorer, Mozilla Firefox 1.5 exibits the exact same behaviour.

If you enable automatic character set detection either browser will trigger the XSS without the call to the header() function. The difference is that in Firefox to trigger the header-less problem the auto-detection needs to be configured to detect utf-7. If it is not, then the exploit does not happen.

Posted in Google XSS Example.

Wed, 21 Dec 2005 at 23:35:53 GMT