public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
	"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] fix #3389: Skip CSRF token check also for API tokens on file upload
Date: Thu, 22 Apr 2021 10:08:56 +0200	[thread overview]
Message-ID: <4d601bee-3c3d-a8a2-f376-01f1b100de4c@proxmox.com> (raw)
In-Reply-To: <1619074571.4va2rkfmko.astroid@nora.none>

On 22.04.21 10:05, Fabian Grünbichler wrote:
> On April 21, 2021 1:59 pm, Lorenz Stechauner wrote:
>> On file upload, the check for CSRF tokens was already skipped
>> when performing user authentication.This now happens for API
>> tokens also.
>>
>> Signed-off-by: Lorenz Stechauner <l.stechauner@proxmox.com>
>> ---
>>  PVE/HTTPServer.pm | 34 +++++++++++++++++-----------------
>>  1 file changed, 17 insertions(+), 17 deletions(-)
>>
>> diff --git a/PVE/HTTPServer.pm b/PVE/HTTPServer.pm
>> index 64976c7c..63b8583e 100755
>> --- a/PVE/HTTPServer.pm
>> +++ b/PVE/HTTPServer.pm
>> @@ -79,8 +79,8 @@ sub auth_handler {
>>  
>>      if ($require_auth) {
>>  	if ($api_token) {
>> +	    # returns tokenid actually
>>  	    $username = PVE::AccessControl::verify_token($api_token);
>> -	    $rpcenv->set_user($username); #actually tokenid in this case
>>  	} else {
>>  	    die "No ticket\n" if !$ticket;
>>  
>> @@ -94,25 +94,25 @@ sub auth_handler {
>>  		die "No ticket\n"
>>  		    if ($rel_uri ne '/access/tfa' || $method ne 'POST');
>>  	    }
>> +	}
>>  
>> -	    $rpcenv->set_user($username);
>> -
>> -	    if ($method eq 'POST' && $rel_uri =~ m|^/nodes/([^/]+)/storage/([^/]+)/upload$|) {
>> -		my ($node, $storeid) = ($1, $2);
>> -		# we disable CSRF checks if $isUpload is set,
>> -		# to improve security we check user upload permission here
>> -		my $perm = { check => ['perm', "/storage/$storeid", ['Datastore.AllocateTemplate']] };
>> -		$rpcenv->check_api2_permissions($perm, $username, {});
>> -		$isUpload = 1;
>> -	    }
>> +	$rpcenv->set_user($username);
>>  
>> -	    # we skip CSRF check for file upload, because it is
>> -	    # difficult to pass CSRF HTTP headers with native html forms,
>> -	    # and it should not be necessary at all.
>> -	    my $euid = $>;
>> -	    PVE::AccessControl::verify_csrf_prevention_token($username, $token)
>> -		if !$isUpload && ($euid != 0) && ($method ne 'GET');
>> +	if ($method eq 'POST' && $rel_uri =~ m|^/nodes/([^/]+)/storage/([^/]+)/upload$|) {
>> +	    my ($node, $storeid) = ($1, $2);
>> +	    # we disable CSRF checks if $isUpload is set,
>> +	    # to improve security we check user upload permission here
>> +	    my $perm = { check => ['perm', "/storage/$storeid", ['Datastore.AllocateTemplate']] };
>> +	    $rpcenv->check_api2_permissions($perm, $username, {});
>> +	    $isUpload = 1;
>>  	}
>> +
>> +	# we skip CSRF check for file upload, because it is
>> +	# difficult to pass CSRF HTTP headers with native html forms,
>> +	# and it should not be necessary at all.
>> +	my $euid = $>;
>> +	PVE::AccessControl::verify_csrf_prevention_token($username, $token)
>> +	    if !$isUpload && ($euid != 0) && ($method ne 'GET');
> 
> this verify_csrf_prevention_token call was never triggered for API 
> tokens before, on purpose - one of the design goals of API tokens was to 
> provide stateless API access without requiring round-trips like our 
> regular, ticket-based sessions do. CSRF-prevention also does not make 
> much sense outside of the browser context (whereas API tokens are for 
> automated access by non-browser clients).
> 
> with this change we'd now suddenly require CSRF tokens for API tokens as 
> well, and IIRC API tokens can't even get one of those (and even if they 

> could, none of the existing clients would know about that and could no 
> longer do any non-GET requests with tokens).
> 
> I think (but I haven't tested it!) that
> - setting $isUpload for the API token case as well
> - leaving the CSRF check limited to regular (non-API-token) authentication
> 
> should give us the desired effect without any side-effects. the actual 
> upload handling is in PVE::APIServer::AnyEvent and just seems to check 
> for $isUpload in the result of auth_handler.
> 

you're right, good catch! @Lorenz, care to send out a patch bringing it
back it shape?





      reply	other threads:[~2021-04-22  8:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21 11:59 Lorenz Stechauner
2021-04-22  8:03 ` [pve-devel] applied: " Thomas Lamprecht
2021-04-22  8:05 ` [pve-devel] " Fabian Grünbichler
2021-04-22  8:08   ` Thomas Lamprecht [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4d601bee-3c3d-a8a2-f376-01f1b100de4c@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal