[ZendTo] Re: Results of Penetration Testing on Zendto

[Jules]

Thanks for that. A few comments in-line below.

On 22/08/2011 08:43, patrick.gaikowski at kaufland.com wrote:
>
> Hi,
>
> we ordered an external company specialised for Penetration testing to 
> take a look to zendto. The found some weaknesses which should be 
> corrected...
>
> *1.) Session-Concept*
>
> The user is identified by a Cookie-Value. The Cookie Value consists of 
> username, IP-address, timestamp, Nuonce, browser, Cookie-name and 
> serversite secret. All these values are combined and hashed with MD5.
> This hash is used together with username, IP-address, timestamp, 
> Nuonce to identify the user.
>
> The user sends the Cookie-Values to the server and the server checks 
> if the hash is correct and the timestamp is not too old.
>
> *Suggestion:*
>
> The external company mentions that there is no additional measures to 
> check if the user is really connecting from that IP-address.
>
Wrong. See line 999 of NSSDropbox.php.
>
> The security is only based on the serversite secret.
>
Not true, because of my comment above. You have to be coming from the 
right IP address as well, or else line 999 will chuck you out.
>
> With brute force it should be possible to get the MD5-Hash and imitate 
> every user.
> The suggestion is to extend the serversite secret to 20 characters
>
It's already 32 characters.
>
> and change it continously.
>
That makes it very hard to verify users, doesn't it? What happens if 
someone is logged in during a change of the serversite secret? All of a 
sudden their cookies would become invalid. Things like ssh can change 
the secret because there is out-of-band communication between the server 
and the client. I do not have that luxury in a web browser.
>
> The status of a Session should be verified on serversite.
>
> *2.) Cookie*
>
> The cookie "zendto-session" is not marked with (php) attributes like 
> "secured"
>
Cannot do that as ZendTo may well not be run over https, that's up to 
the site administrator. Particularly for trial purposes, it may well be 
run over http.
>
> and "HttpOnly".
>
Agreed. Done.
>
>
> *Suggestion:*
>
> All cookies should be marked with "Secure" and "HttpOnly" to 
> complicate the sniffing of these values.
>
See above.
>
>
> *3.) Reflected Cross-Site-Scripting*
>
> The Vulnerability was found in the following URL:
>
> https://<IP>/pickup.php?claimID=D9tEmVyPzfpaWW3cd541b"><img src="noex" 
> onerror="alert('SySS 
> XSS!')"&claimPasscode=TD9ab87Sas2RFVoW&pickup=Pick-up+the+File(s)
>
Well spotted. I missed one. Fixed.

Many thanks for that. The fixes I've mentioned above will be in the next 
release.

Jules

-- 
Julian Field MEng CITP CEng
www.Zend.To

Follow me at twitter.com/JulesFM
PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654

'It's okay to live without all the answers' - Charlie Eppes, 2011
'All programs have a desire to be useful' - Tron, 1982
'That is the land of lost content,
  I see it shining plain,
  The happy highways where I went,
  And cannot come again.' - A.E. Houseman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/zendto/attachments/20110822/cacc0760/attachment.html