2009/3/11 Daniel Brown <danbrown@xxxxxxx>: > On Wed, Mar 11, 2009 at 12:38, Jan G.B. <ro0ot.w00t@xxxxxxxxxxxxxx> wrote: >> wrong: >> "Location: file.txt" >> and this is correct >> "Location: http://www.x.x/file.txt"; >> >> Not all clients behave like yours and accept the wrong header. > > The *protocol* does not, but the HTTP/1.1 specification does. > However, it should be noted that *all* modern browsers accept relative > URI's vs. the requirement of absolute URI's. Thus, the header is > "non-standard," but is not "wrong." Your point is accurate, though: > it should include the full resource. > >> erm .... <META> should be in a html document inside the <HEAD>, not *anywhere*. > > That's the recommended order, but it's not required. Not even in > 1982 when the spec was written. In fact, the placement in HEAD is so > that, with the original specifications, a server would be permitted > (though again, not required) to read the META tags within HEAD to form > and send its own headers via HTTP in conjunction with the plain-text > data from the document. > >> Very, very, very bad idea. You just opened a cross site scripting bug. >> >> Imagine someone opens this URL >> host/yourfile?id="><script>alert(document.cookie)</script> >> >> You must always escape any input you take. >> see http://php.net/security > > This is always true of any user-side input being sent to a script > (though the example may seem a little humorous because, if a person is > that desperate to see their cookie data, their browser truly sucks). > > Once again, for anyone who hasn't been paying attention or who > doesn't yet have the acquired knowledge from their own painful > experiences, *never* copy and paste code from this list or any other > medium. Always evaluate it yourself first. This list is meant for > assistance and those on it provide "pseudocode," not production-worthy > code. The rest is, as has always been, at your own risk. > Where's your point? Proving that you know the well known clients and their behaviour? Just stick to the standards. easy. no or less errors occur. Also, it's quite clear to any thinking person, that alerting the cookie is an example that shows how easy an attacker can catch the session id. it's a well known common example. it's more humorous that your choice is to ignore or fight RFCs, open standards and that you don't even know the most common XSS example - but that is just my opninion. :-) have a nice day. > </Daniel P. Brown> > 50% Off All Shared Hosting Plans at PilotPig: Use Coupon x stop spamming me, thanks. :-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
