On Tue, 6 Feb 2018, Dan Fandrich wrote:
There looks like a large degree of overlap with
https://curl.haxx.se/libcurl/c/libcurl-tutorial.html#Security Perhaps that
document could be expanded instead of duplicating the info.
I...
1. ripped out the security section from there
2. created libcurl
On Thu, 8 Feb 2018, bch wrote:
Over time we've (reluctantly) added adaptions when curl users have
suffered.
Is there a way to see what “quirks” have been applied to URLs ? It’d be
illustrative to see or retrieve info that says: “cURL adapted for
scheme/slash count”, or “automatic encoding em
On Thu, Feb 8, 2018 at 8:58 AM Daniel Stenberg wrote:
> On Thu, 8 Feb 2018, Dennis Clarke wrote:
>
> > There is nothing wrong with RFC-3986 nor the more specific RFC-8089.
>
> RFC 3986 is for generic URIs. RFC 8089 is for the specific subset file:
> URIs.
> They're different beasts.
>
> The "wron
On Thu, 8 Feb 2018, Dennis Clarke wrote:
There is nothing wrong with RFC-3986 nor the more specific RFC-8089.
RFC 3986 is for generic URIs. RFC 8089 is for the specific subset file: URIs.
They're different beasts.
The "wrong" about 3986 is that people and software are more and more often
u
FYI: WHATWG is a sort of standards organization, similar to W3C and
IETF. It was created by a bunch of browser vendors and they have a
strong browser focus with participation representation from all the
major browsers.
I see rfc-8089 as the spec that tells us about a "file" or some blob
On Wed, 7 Feb 2018, Pete Lomax wrote:
A couple of quick points:
"Localhost is hard to protect" says "may be possible to exploit to
"port-scan" the particular hosts". I think that needs a slight rewording.
What's not clear about that? You want me to elaborate on what port-scanning is
or why
On Wed, 7 Feb 2018, Dan Fandrich wrote:
If the application/script sets --netrc then an attacker would just need to
supply a username and curl would fill in the password, allowing attacks on
machines that honoured those credentials (probably only local machines). And
if --negotiate or --ntlm ar
On Tue, Feb 06, 2018 at 01:47:50PM +0100, Daniel Stenberg wrote:
> But in the context of "dangerous things", how do see the user + password in
> the URL used to harm the application or the server?
If the application/script sets --netrc then an attacker would just need to
supply a username and curl
A couple of quick points:
"Localhost is hard to protect" says "may be possible to exploit to "port-scan"
the particular hosts". I think that needs a slight rewording.
I had never heard of WHATWG - perhaps a link to
https://daniel.haxx.se/blog/tag/whatwg/ (etc) might be helpful.
Pete
---
On Tue, Feb 6, 2018 at 4:52 AM Daniel Stenberg wrote:
> On Tue, 6 Feb 2018, Christian Schmitz wrote:
>
> > Can we disallow login & password in URLs? e.g. get an option to make
> perform
> > fail with error, if there is a @ in the URL before domain?
>
> That seems like it should be a pretty straig
On Tue, Feb 06, 2018 at 08:24:41AM +0100, Daniel Stenberg wrote:
> Every now and then we get security problems reported to us that are really
> just various types of attacks you can do if you can either A) modify the url
> your curl application is using and/or B) have a server respond with a
> perf
On Tue, 6 Feb 2018, Christian Schmitz wrote:
Can we disallow login & password in URLs? e.g. get an option to make perform
fail with error, if there is a @ in the URL before domain?
That seems like it should be a pretty straight forward thing to add, sure!
But in the context of "dangerous thin
> Am 06.02.2018 um 08:24 schrieb Daniel Stenberg :
>
> Hi friends,
> Letting users freely set the URL, or parts of the URL, for your curl-using
> application can get consequences.
>
Can we disallow login & password in URLs?
e.g. get an option to make perform fail with error, if there is a @ in
13 matches
Mail list logo
