spark-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ankit Jain <ankitjain....@gmail.com>
Subject Re: Turning off Jetty Http Options Method
Date Wed, 01 May 2019 05:04:27 GMT
I agree for an OSS project all end points that can be called are already
publicly available.

https://security.stackexchange.com/questions/138567/why-should-the-options-method-not-be-allowed-on-an-http-server
has
couple of good reasons though.

"An essential part of security is to reduce the attack surface by removing
any functionality which is not needed. Usually this is also functionality
which is less well tested and thus might be a vector for unexpected
attacks."

2nd answer is more ominous-
"Others have pointed out that you want to limit your attack surface, and to
be aware that some Ajax sites legitimately use OPTIONS. Anyway, I wanted to
share a recent experience with you.

We had tested a site and discovered it was vulnerable to executable file
upload. Roughly speaking, you could upload a JSP file as your profile
picture, then execute the JSP file and take control of the server.

The client's first attempt at a fix blocked fetching the JSP with a GET
request. However, we discovered it was still possible to execute the JSP
using an OPTIONS request. You don't get the JSP output - but it's easy to
code the JSP to connect back with an out-of-band mechanism.

In this case, allowing OPTIONS allowed a remote server compromise."

Thanks

Ankit

On Tue, Apr 30, 2019 at 7:35 PM <email@yeikel.com> wrote:

> If this is correct *“**This method exposes what all methods are supported
> by the end point” , *I really don’t understand how’s that a security
> vulnerability considering the OSS nature of this project. Are you adding
> new endpoints to this webserver?
>
>
>
> More info about info/other methods :
> https://security.stackexchange.com/questions/21413/how-to-exploit-http-methods
>
>
>
>
>
> *From:* Ankit Jain <ankitjain.dce@gmail.com>
> *Sent:* Tuesday, April 30, 2019 7:25 PM
> *To:* user@spark.apache.org; dev@spark.apache.org
> *Subject:* Re: Turning off Jetty Http Options Method
>
>
>
> + *dev*@*spark*.apache.org
>
>
>
> On Tue, Apr 30, 2019 at 4:23 PM Ankit Jain <ankitjain.dce@gmail.com>
> wrote:
>
> Aah - actually found https://issues.apache.org/jira/browse/SPARK-18664 -
> "Don't respond to HTTP OPTIONS in HTTP-based UIs"
>
>
>
> Does anyone know if this can be prioritized?
>
>
>
> Thanks
>
> Ankit
>
>
>
> On Tue, Apr 30, 2019 at 1:31 PM Ankit Jain <ankitjain.dce@gmail.com>
> wrote:
>
> Hi Fellow Spark users,
>
> We are using Spark 2.3.0 and security team is reporting a violation that
> Spark allows HTTP OPTIONS method to work(This method exposes what all
> methods are supported by the end point which could be exploited by a
> hacker).
>
>
>
> This method is on Jetty web server, I see Spark uses Jetty for web UI and
> some internal communication as well.
>
>
>
> For Spark UI, we are planning to write a javaxfiler, create a jar and add
> it to spark libs to not respond to options method. We don't have a clean
> solution for internal jetty server that is used as a file server though.
>
>
>
> It will be nice if Spark itself didn't allow Options method to work,
> similar to what was done for TRACE -
> https://issues.apache.org/jira/browse/SPARK-5983
>
>
>
> What do you guys think? Does community feel this should be something added
> directly to spark code?
>
>
>
> Also, if there is a later version of Spark where this has been addressed,
> please let us know too.
>
>
>
> --
>
> Thanks & Regards,
>
> Ankit.
>
>
>
>
> --
>
> Thanks & Regards,
>
> Ankit.
>
>
>
>
> --
>
> Thanks & Regards,
>
> Ankit.
>


-- 
Thanks & Regards,
Ankit.

Mime
View raw message