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 <em...@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....@gmail.com> > *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 <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 <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. > -- Thanks & Regards, Ankit.
