Re: Turning off Jetty Http Options Method

2019-04-30 Thread Ankit Jain
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  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 
> *Sent:* Tuesday, April 30, 2019 7:25 PM
> *To:* user@spark.apache.org; d...@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 
> 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 
> 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.


RE: Turning off Jetty Http Options Method

2019-04-30 Thread email
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  
Sent: Tuesday, April 30, 2019 7:25 PM
To: user@spark.apache.org; d...@spark.apache.org
Subject: Re: Turning off Jetty Http Options Method

 

+ d...@spark.apache.org <http://apache.org> 

 

On Tue, Apr 30, 2019 at 4:23 PM Ankit Jain mailto:ankitjain@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 mailto:ankitjain@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.



Re: Turning off Jetty Http Options Method

2019-04-30 Thread Ankit Jain
+ d...@spark.apache.org

On Tue, Apr 30, 2019 at 4:23 PM Ankit Jain  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 
> 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.


Re: Turning off Jetty Http Options Method

2019-04-30 Thread Ankit Jain
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  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.