Add -NoProxy parameter to Invoke-WebRequest

[joeyaiello]

This request came in from UserVoice, and I think it might make sense, but I'm also curious if there's a security implication here (i.e. if an admin sets a proxy globally, could a user override it with this parameter?)

Steps to reproduce

Set up a system-wide proxy and run:

Invoke-WebRequest -NoProxy www.github.com

Expected behavior

The request doesn't go through the system-wide proxy.

Actual behavior

The request does go through the system-wide proxy.

[iSazonov]

I believe there is not security implication here because any browser allow users to change Proxy settings.

We could use Uri = Null to disable proxy:

Invoke-WebRequest -Proxy $null

[mcwidg3t]

In my testing, "-Proxy $null" does not work. The request still goes to the system proxy.

[iSazonov]

It was my suggestion to implement.

[TheFlyingCorpse]

A downside of using -Proxy $null would be that it would override any DefaultWebProxy, every time, which means you would have had to specify the proxy on every request.

What about -Proxy $false?

[iSazonov]

@TheFlyingCorpse We cannot change type (it is Uri) of the Proxy parameter.

[TheFlyingCorpse]

I see. a -NoProxy would be the way to go then.

[TheFlyingCorpse]

I have a patch right around the corner that fixes this. It introduces a -NoProxy parameter.

[thezim]

@iSazonov if your workstation is under enterprise control typically you cannot change your proxy settings. Allowing so would subvert the security policy that is in place.

[SteveL-MSFT]

@thezim however, if they have access to powershell, they could circumvent it today calling the .Net APIs directly.

[thezim]

@SteveL-MSFT if one has the means (.NET API) to enter your home would you leave the front door unlocked (-NoProxy) to make it easier?

[SteveL-MSFT]

Alternatively, if you want policy enforced, this should be done within corefx

[iSazonov]

On Windows we can block changing of proxy setting in IE by means of GPO but users is free to change the setting in any other third party agent (Firefox, Chrome, Opera, wget and so on).

[TheFlyingCorpse]

Plus its possible to wipe it via reg.exe / regedit.
If you dont want your users to access the internet without proxy, you dont have 80 and 443 open to the internet from your relevant networks. Simple as that.

[mcwidg3t]

The System Proxy settings in an enterprise environment are a management convenience. It's not a security setting. Security is better handled by blocking 80 and 443 at the firewall.

[thezim]

@iSazonov GPO's exist for third party browsers as well. In my enterprise FF is locked down too. Stack on host based security system managed at the enterprise level and changing settings becomes very difficult. No installing unauthorized applications, running registry editors, etc.

@TheFlyingCorpse registrys keys have ACLs on them to prevent this and is considered a best practice.

@mcwidg3t I agree port blocking is be best solution but security is should be multi layered and should should never depend on a single layer. Hacker's count on admins thinking they are safe to great effectiveness.

[mcwidg3t]

@thezim if you remove Powershell from the client desktop then you've removed a potential security hole, which also makes sense from a layered security approach. However, you also may be impacting productivity. It's a balancing act.

In this case, I think that any increased risk in having a -NoProxy parameter is minimal given there are more appropriate ways at handling the security. I think it's a useful feature to have so for me, I'd implement it.

[SteveL-MSFT]

@thezim I think enterprises can still lock this down by having a proxy function in PowerShell that doesn't expose -noproxy

[joeyaiello]

First, this is implemented in #3447

This thread is all conjecture until someone investigates whether the proposed APIs we're using respect enterprise controls that limit proxy settings. From what I can see, we're basically just passing false to an instance of HttpClientHandler.UseProxy.

If HttpClientHandler doesn't respect enterprise controls, and you're not limiting PowerShell environments in any way, there's already a gaping hole. Anyone could replicate what's going on here without a cmdlet later. Creating "convenience" for hackers is not a sound argument (most PowerShell malware out there is highly obfuscated already, they don't care about convenience).

Giving the PR my 👍

[iSazonov]

Someday CoreFX integrates Authorization Manager 😄

[mcwidg3t]

Good news @joeyaiello. Looking forward to that being released.