AW: Issue with Outputting CURL Verbose Info to a File

[Patrick Schlangen]

Hi,

> but it never seems to output anything to the file

try passing a FILE * to the curl_easy_setopt instead of a FILE &.

Best Regards

Patrick




---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Issue with Outputting CURL Verbose Info to a File

[Chris Molnar]

 Hi All,

I seem to be running into a problem when trying to output the verbose info
to a file. I have set it up to send using curl_easy_setopt(curl, CURLOPT,
file) as it shows on the website (the first 2 links below) but it never
seems to output anything to the file. I looked further into this problem
and found that someone had the same problem but the suggested solution only
seemed to work on Linux and not Windows (as seen in the 3rd link). I was
wondering if anyone had any knowledge of this being a problem on Windows
devices or a possible work around? I have attached a snippet of my code
below.

Thank you for your time and help

References:
https://curl.haxx.se/libcurl/c/CURLOPT_STDERR.html
https://curl.haxx.se/libcurl/c/CURLOPT_VERBOSE.html
https://stackoverflow.com/questions/38720602/getting-verbose
-information-from-libcurl-to-a-file
// Sends the request to the license server to validate activation
std::string testFile = "test.txt";

bool curlPostFile(FILE ) {
	CURL *curl = curl_easy_init();
	std::string read;
	struct curl_httppost *post;
	struct curl_httppost *postend;

	post = NULL;
	postend = NULL;
	curl_formadd(, ,
		CURLFORM_COPYNAME, "userfile",
		CURLFORM_FILE, testFile.c_str(),
		CURLFORM_CONTENTTYPE, "text/plain",
		CURLFORM_END)

	//connecting to the server
	curl_easy_setopt(curl, CURLOPT_URL, postRequestURL.c_str());
	curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 1L);
	curl_easy_setopt(curl, CURLOPT_MAXREDIRS, 50L);
	curl_easy_setopt(curl, CURLOPT_HTTPPOST, post);

	// This is against a local server so no need for SSL verification
	curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L);
	curl_easy_setopt(curl, CURLOPT_STDERR, log);
	curl_easy_setopt(curl, CURLOPT_CAINFO, "selfsignedcert.crt");
	curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 2L);
	curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L);
	curl_easy_setopt(curl, CURLOPT_PORT, 443L);
	curl_easy_perform(curl);
	curl_easy_cleanup(curl);
	return true;
}---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: "URLs are dangerous things"

[bch]

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 straight forward thing to add, sure!
>
> 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 it’s a good idea at all, would a sane implementation method (and
generalization) be string blacklisting (maybe preloaded w “@“, etc, for
example)? I don’t have the cURL src in front of me, and I don’t know if
“components” are testable (I.e..: “the part before the domain”), or if a
regexp would fit the bill (or, perhaps both, instead of positing a false
dichotomy, and being aware of “The Center Cannot Hold”[0]). Not entirely
clear something like this “belongs” in cURL, but if there’s enough interest
and value, probably good to have something centralized. “@“ turned out to
be more interesting to me than I’d have imagined...


[0] https://stackoverflow.com/a/1732454




> > And the Use SSL options being 3 would it fail with HTTP:// URL?
>
> CURLOPT_PROTOCOLS is the option to enable/disable specific protocols.
> There's
> no generic "disable all non-authenticated protocols" option.
>
> Of course, an interesting idea is to let CURLOPT_USE_SSL affect *all*
> protocols so that you can require TLS/SSL to be used with that option even
> for
> HTTP(S). But that's not how that option works right now...
>
> --
>
>   / daniel.haxx.se
> ---
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette:   https://curl.haxx.se/mail/etiquette.html
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: "URLs are dangerous things"

[Dan Fandrich]

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
> perfectly fine protocol-wise but malicious response to curl.
> 
> Letting users freely set the URL, or parts of the URL, for your curl-using
> application can get consequences.
> 
> I've started to document exactly what consequences and how:

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.
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: "URLs are dangerous things"

[Daniel Stenberg]

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 things", how do see the user + password in 
the URL used to harm the application or the server?



And the Use SSL options being 3 would it fail with HTTP:// URL?


CURLOPT_PROTOCOLS is the option to enable/disable specific protocols. There's 
no generic "disable all non-authenticated protocols" option.


Of course, an interesting idea is to let CURLOPT_USE_SSL affect *all* 
protocols so that you can require TLS/SSL to be used with that option even for 
HTTP(S). But that's not how that option works right now...


--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: "URLs are dangerous things"

[Christian Schmitz]

> 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 the URL 
before domain?

And the Use SSL options being 3 would it fail with HTTP:// URL?

Sincerely
Christian

-- 
Read our blog about news on our plugins:

http://www.mbsplugins.de/



---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html