I wrote:
It's easy enough to find out if REQUEST_URI is available. What we
don't know is whether REQUEST_URI is really what was sent to the
server, or whether it has %2E converted to . before PHP gets to see it.
I installed IIS on my Windows VM and checked this. I installed PHP
from the MSI
On 04/06/11 03:53, Brion Vibber wrote:
On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling tstarl...@wikimedia.orgwrote:
The main issue here is that we don't a wide variety of web servers set
up for testing. We know that Apache lets you detect %2E versus dot via
$_SERVER['REQUEST_URI'], but we don't
On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling tstarl...@wikimedia.orgwrote:
On 03/06/11 06:56, Brion Vibber wrote:
For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at this
point; the vendor's dropped support, shipped three major versions, and is
actively campaigning to get
Is there a way we can narrow down this security check so it doesn't keep
breaking API requests, action=raw requests, and ResourceLoader requests,
etc?
Having the last param in a query string end in say .png or .svg or
.jpg or .ogg is. very frequent when dealing with uploaded files and
file
On Thu, Jun 2, 2011 at 10:56 PM, Brion Vibber br...@pobox.com wrote:
Is there a way we can narrow down this security check so it doesn't keep
breaking API requests, action=raw requests, and ResourceLoader requests,
etc?
Tim had an idea about redirecting bad URLs to fixed ones. He ran it by
me
Remember Rule #1: You can't solve social problems using technical means. The
social problem is that people keep using IE6. The technical means are to
protect them by pandering to IE6 security lapses. The social solution is to
tell people FFS, STOP USING IE^111.
For all the reasons Brion gave
On Thu, Jun 2, 2011 at 2:20 PM, Roan Kattouw roan.katt...@gmail.com wrote:
On Thu, Jun 2, 2011 at 10:56 PM, Brion Vibber br...@pobox.com wrote:
Is there a way we can narrow down this security check so it doesn't keep
breaking API requests, action=raw requests, and ResourceLoader requests,
Varnish for load.php) between us and the IE users, and I'm not sure we
can tell them to only not cache requests for IE6.
This might work:
acl ffsnoie6 browser ie6
no_cache deny ffsnoie6
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On Thu, Jun 2, 2011 at 5:25 PM, Russell N. Nelson - rnnelson
rnnel...@clarkson.edu wrote:
Remember Rule #1: You can't solve social problems using technical means. The
social problem is that people keep using IE6. The technical means are to
protect them by pandering to IE6 security lapses. The
On Thu, Jun 2, 2011 at 11:39 PM, Brion Vibber br...@pobox.com wrote:
I know this has already been brought up, but that doesn't work for POST, and
may not work for API clients that don't automatically follow redirects.
That's exactly what Tim said. However, I don't think POST is that much
of a
On Thu, Jun 2, 2011 at 2:44 PM, Roan Kattouw roan.katt...@gmail.com wrote:
However, I don't think POST is that much
of a problem. Problematic dots can only result from 'variable' pieces
of data being put in your query string, and with POST you'd typically
put the variable parts in the POST
Look, we're moving into a new generation of web browsers. It's time to
upgrade - it's easy and free. We shouldn't spend our time/resources trying
to support ten-year-old technology. Even Microsoft is trying to get people
to stop and it's the responsibility of any popular website to support modern
Brion Vibber wrote:
On Thu, Jun 2, 2011 at 2:20 PM, Roan Kattouwroan.katt...@gmail.com wrote:
On Thu, Jun 2, 2011 at 10:56 PM, Brion Vibberbr...@pobox.com wrote:
Is there a way we can narrow down this security check so it doesn't keep
breaking API requests, action=raw requests, and
On Thu, Jun 2, 2011 at 6:06 PM, Mono mium monom...@gmail.com wrote:
Look, we're moving into a new generation of web browsers. It's time to
upgrade - it's easy and free. We shouldn't spend our time/resources trying
to support ten-year-old technology. Even Microsoft is trying to get people
to
On 03/06/11 06:56, Brion Vibber wrote:
The impression I get is this is:
1) only exploitable on IE 6 (which is now a small minority and getting
smaller)
IE 6 and some earlier versions of IE, at least back to 4.
2) only exploitable if the path portion of the URL does not include an
Brion Vibber wrote:
Your ideas to secure api.php output against HTML abuse are
interesting, but I don't think the txt and dbg formats can be fixed
that way.
Why do we actually have these extra unparseable formats? If they're for
debug readability then we can probably just make them
On 03/06/11 07:20, Roan Kattouw wrote:
Tim had an idea about redirecting bad URLs to fixed ones. He ran it by
me last night his time, and my guess is he'll probably implement it
this morning his time. But I'll leave it up to him to elaborate on
that.
I committed it in r89397. It's
17 matches
Mail list logo
