TAP, automated site monitoring, and gzip encoding.

[Paul Harrison]

On 2011-06 -30, at 21:35, Tom McGlynn wrote:

> NASA sites are a prominent target for hackers and so Goddard uses automated tools that look for a variety of exploits including SQL injection attacks.  Currently TAP schema queries can trigger these. While our security folks don't want to be too specific as to what the triggers are I believe that the combination of:
> 
>   Support of arbitrary SQL in the query
>   Lack of passwords
>   Results that look like table schemas (because they are)
>   Output in clear text
> 
> play a major role in making things look suspicious.  While they can turn off checking altogether that would mean that any real successful SQL injection attack could go undetected and we have lots of attempts every day.
> 
> One solution that I had hoped might work was to use a GZIP transfer encoding (or content encoding) for the query results.  Unfortunately it doesn't look like clients currently note the HTTP encoding headers.
> 
> NASA is probably a bit more paranoid about this than some, but I suspect that this will become a more common issue as time goes on.
> Support for content or transfer encoding is an HTTP level issue so I don't think it requires any change to the TAP standard, just clients that look for the appropriate HTTP headers.  Would it be reasonable to request that clients support gzip encoding?  In addition to address this security issue I suspect this would generally substantially decrease the size of downloaded data and make our queries more responsive.
> 

Surely the appearance of SQL in the query is the what triggers the anti-hack filter - the results cannot be the cause as they are in VOTable and I would be very surprised if any anti-hacker tools know about VOTable....
So I bet looking for some form of encoding for the query would be more effective in this case - however if it was any sort of standard encoding then the anti-hacker tool ought to be decoding it anyway if it is any good, so I think that would not work either...

SQL injection attacks are a legitimate concern for the implementors of TAP servers too -  don't pass the query in a raw unparsed state straight to your database in your TAP server...So I think that the TAP server implementations have to be the guardians in this case and the general anti-hack tool turned off for the TAP servers...


Paul.