[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #22062 [Metrics/Onionoo]: Bad requests do not add the Access-Control-Allow-Origin header



#22062: Bad requests do not add the Access-Control-Allow-Origin header
---------------------------------+--------------------------
     Reporter:  cypherpunks      |      Owner:  metrics-team
         Type:  defect           |     Status:  new
     Priority:  Medium           |  Milestone:
    Component:  Metrics/Onionoo  |    Version:
     Severity:  Normal           |   Keywords:
Actual Points:                   |  Parent ID:
       Points:                   |   Reviewer:
      Sponsor:                   |
---------------------------------+--------------------------
 I've found this issue by submitting invalid requests through Atlas. For
 example, https://atlas.torproject.org/#search/%3Ctest%3E shows in the
 Firefox Developer Tools Console tab the following message.
 > Cross-Origin Request Blocked: The Same Origin Policy disallows reading
 the remote resource at
 https://onionoo.torproject.org/summary?search=%3Ctest%3E. (Reason: CORS
 header 'Access-Control-Allow-Origin' missing).

 Looking at the Onionoo code, the culprit seems to be the doGet function
 and more specifically
 [https://gitweb.torproject.org/onionoo.git/tree/src/main/java/org/torproject/onionoo/server/ResourceServlet.java?id=7d673c8bcc3e1d71c2fe5439653a98e758cc13f5#n356
 ResourceServlet.java:356] which sets several headers but only when the
 request has been processed successfully. For invalid requests it calls
 sendError. According to the Java API
 [https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletResponse.html
 #sendError-int- sendError]
 > Sends an error response to the client using the specified status code
 and clears the buffer. The server will preserve cookies and may clear or
 update any headers needed to serve the error page as a valid response. If
 an error-page declaration has been made for the web application
 corresponding to the status code passed in, it will be served back the
 error page
 I'm not sure which headers sendError clears or updates but I think the
 setHeader calls can safely be moved to the top of the doGet function to
 ensure these headers are also included in bad request responses.
 Unfortunately i have no setup to test this assumption/solution.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22062>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs