Re: login cgi argument sanity checking

[Cory Snavely <csnavely@xxxxxxxxx>]

I haven't seen any response on this thread, but FWIW, I think this is a 
good catch and is probably worth some small improvements to prevent 
potential problems.

(I will occasionally see strings like "|cat /etc/passwd" passed as a CGI 
argument to web applications we run, and thoroughly roll my eyes at such 
pathetic attempts, but it goes to show that some folks will try an 
exploit in any conceivable place.)

It seems to me that the full-out proper behavior would be for CoSign to 
apply the same normalization as Kerberos authentication does, and then 
pass along the normalized result. I.e., interpret \a as a and modify the 
string. Stripping non-legit characters would also be an acceptabe 
approach to me.

Neither of these are requests, but rather just feedback on the topic.

c

Graeme Wood wrote:
> One of our users has discovered by accident that the login CGI will accept
> a backslash in the username and will correctly authenticate to the KDC,
> presumably because the backslash is regarded by the krb functions as just
> quoting the following character. However, cosign retains the backslash in
> the authenticated username and so the backslash appears in the REMOTE_USER
> environment variable when it is read by mod_cosign.  This then affects
> authorisation.
>
> It doesn't look like cgi.c does any sanity checking of the login argument
> that is passed to it from the html form.  It should probably check that
> only alphanumeric characters are accepted (and perhaps / to allow for
> non-default principals), though this might affect non-ascii usernames (do
> people use multicharacter usernames?). What do people think?