You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by "eberhard speer jr." <se...@ducis.net> on 2013/05/13 17:22:24 UTC
UA in query string
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I agree that *if* a form is used and *if* the URL parameters are
encoded the 'problem' of putting an ua-string in an URL's
query-string, is largely academic.
Unfortunately, the 'baddies' will craft all kinds of 'clever'
requests, breaking all these rules, throwing in the kitchen-sink, etc.
At the very least it'll keep the server/service busy with all kinds of
avoidable nonsense.
But apart from the malicious and far-fetched stuff, here's a scenario
which I believe is quite common (like at this site) : one or more
reverse proxies are used for load-balancing, authentication, caching
and all the other clever things they do.
Taking the set-up here as example : because I know none of the web
servers run PHP, the proxies drop all requests that include the
extension ".php". (along with .js, .jsp etc)
There is simply no point in forwarding such requests and dropping them
(occasionally, responding with 418 for laughs) cuts off all those
obnoxious scans for 'known' php files, directories and 'weaknesses'.
Similarly, the proxies deny these URL sequences :
.. ; Don't allow directory traversals
./ ; Don't allow trailing dot on a directory name
\ ; Don't allow backslashes in URL
: ; Don't allow alternate stream access
% ; Don't allow escaping after normalization
& ; Don't allow multiple CGI processes to run on a single request
etc
Quite a number of other patterns, which can occur in a 'legal' ua, are
'verboten' as well : URLs in URLs, < >, etc
Running a web service that allows (encoded) ua's in the URL's query
string, in such an environment would be difficult. A considerable
number of bona-fide requests would be dropped unless you either
drastically change the overall proxy-rules or add some complexity to
deal with it.
So, it seems to me that a custom HTTP header for the ua should be a
'standard' option ;-)
With regard to the name of the custom HTTP header (Ddr-User-Agent, in
my proposal, as in "Device Description Request User-Agent") I don't
have any strong opinions.
However, RFC 6648 deprecates the use of the "X-" prefix for
non-standard headers.
(except maybe the 'standard' non-standard headers like x-forwarded-for)
esjr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRkQUwAAoJEOxywXcFLKYcg8EIAIXI0eFG/HLVOH0BepNQnHCv
DmZIYyt+0sKSNvnvad3aisT1uI/zzSif2fd8KY2GYHHuL33y71E8nqQlQ6kV94EJ
Pa2iCGSpETEhjNXqnT715WpANn9Hyppizn/ms8vOTXh/PRacZaKKjMLoqYc4Xx6L
9c3lP3OH17pNIhoSu4Nc/YYx9oRxd2VarXVg2Cz2yuV1jsW1UKo5h9bU88dYKI5R
I2k5zfCht77KmOm8C8UocerOyorH+tw0WMaoKYpGRWSg5vpjdE+Tg5vKBwkKbZLD
VGrR27UjCqH6jrazJBvD0eNc2VIfkfvGRvcWFis7fJLWKp26APynqW1wr9M135Y=
=1ghK
-----END PGP SIGNATURE-----
Re: UA in query string
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, May 13, 2013 at 5:22 PM, eberhard speer jr. <se...@ducis.net> wrote:
> ...Running a web service that allows (encoded) ua's in the URL's query
> string, in such an environment would be difficult. A considerable
> number of bona-fide requests would be dropped unless you either
> drastically change the overall proxy-rules or add some complexity to
> deal with it....
Again, I don't get it ;-)
Any parameter that comes in to your service, whether via an URL query
parameter, HTTP header or telepathic communications, MUST be sanitized
before using it in your code. This means prepared statements in SQL,
cleaning up path names, setting up sensible permissions for the
process that runs your service...all the usual precautions.
So I don't see the difference whether a parameter comes in via a URL
or an HTTP header in terms of security - both need to be sanitized
anyway.
I stick to my opinion - if you want to support a HTTP header in
addition to a URL parameter, fine. This can be made configurable in
our service implementation.
-Bertrand
Re: UA in query string
Posted by Reza <re...@yahoo.com>.
This service is meant to support user inputted User-Agent strings via Javascript for testing, feedback, and discovery purposes. So I think this is a valid design given this use case.
If this service was to be used in a real world scenario, then it would *only* look at the User-Agent header. Down the road, I would like to offer a public endpoint for this service that other sites can use freely. In this scenario I would expect to remove the configurable UA param.
Also, I didn't add a 'Access-Control-Allow-Origin' header to the Java service, so its use cases are restricted. We could even remove the JSONP option.
________________________________
From: eberhard speer jr. <se...@ducis.net>
To: devicemap-dev@incubator.apache.org
Sent: Monday, May 13, 2013 11:22 AM
Subject: UA in query string
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I agree that *if* a form is used and *if* the URL parameters are
encoded the 'problem' of putting an ua-string in an URL's
query-string, is largely academic.
Unfortunately, the 'baddies' will craft all kinds of 'clever'
requests, breaking all these rules, throwing in the kitchen-sink, etc.
At the very least it'll keep the server/service busy with all kinds of
avoidable nonsense.
But apart from the malicious and far-fetched stuff, here's a scenario
which I believe is quite common (like at this site) : one or more
reverse proxies are used for load-balancing, authentication, caching
and all the other clever things they do.
Taking the set-up here as example : because I know none of the web
servers run PHP, the proxies drop all requests that include the
extension ".php". (along with .js, .jsp etc)
There is simply no point in forwarding such requests and dropping them
(occasionally, responding with 418 for laughs) cuts off all those
obnoxious scans for 'known' php files, directories and 'weaknesses'.
Similarly, the proxies deny these URL sequences :
.. ; Don't allow directory traversals
./ ; Don't allow trailing dot on a directory name
\ ; Don't allow backslashes in URL
: ; Don't allow alternate stream access
% ; Don't allow escaping after normalization
& ; Don't allow multiple CGI processes to run on a single request
etc
Quite a number of other patterns, which can occur in a 'legal' ua, are
'verboten' as well : URLs in URLs, < >, etc
Running a web service that allows (encoded) ua's in the URL's query
string, in such an environment would be difficult. A considerable
number of bona-fide requests would be dropped unless you either
drastically change the overall proxy-rules or add some complexity to
deal with it.
So, it seems to me that a custom HTTP header for the ua should be a
'standard' option ;-)
With regard to the name of the custom HTTP header (Ddr-User-Agent, in
my proposal, as in "Device Description Request User-Agent") I don't
have any strong opinions.
However, RFC 6648 deprecates the use of the "X-" prefix for
non-standard headers.
(except maybe the 'standard' non-standard headers like x-forwarded-for)
esjr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRkQUwAAoJEOxywXcFLKYcg8EIAIXI0eFG/HLVOH0BepNQnHCv
DmZIYyt+0sKSNvnvad3aisT1uI/zzSif2fd8KY2GYHHuL33y71E8nqQlQ6kV94EJ
Pa2iCGSpETEhjNXqnT715WpANn9Hyppizn/ms8vOTXh/PRacZaKKjMLoqYc4Xx6L
9c3lP3OH17pNIhoSu4Nc/YYx9oRxd2VarXVg2Cz2yuV1jsW1UKo5h9bU88dYKI5R
I2k5zfCht77KmOm8C8UocerOyorH+tw0WMaoKYpGRWSg5vpjdE+Tg5vKBwkKbZLD
VGrR27UjCqH6jrazJBvD0eNc2VIfkfvGRvcWFis7fJLWKp26APynqW1wr9M135Y=
=1ghK
-----END PGP SIGNATURE-----