Bug Tracker

Modify

Ticket #12040 (closed bug: fixed)

Opened 22 months ago

Last modified 11 months ago

Test against Content Security Policy (CSP)

Reported by: dmethvin Owned by:
Priority: low Milestone: 1.10/2.0
Component: support Version: 1.7.2
Keywords: Cc:
Blocking: Blocked by:

Description

Ticket #11249 fixed a CSP issue with inline styles used for feature detects, but there is currently no unit test to ensure there are no regressions. It seems like we could do this with an iframed test where the web service returned the right Content-Security-Policy header. See  http://www.html5rocks.com/en/tutorials/security/content-security-policy/ for more info.

Change History

comment:1 Changed 22 months ago by dmethvin

  • Priority changed from undecided to low
  • Status changed from new to open
  • Component changed from unfiled to support
  • Milestone changed from None to 1.8

comment:2 Changed 22 months ago by anthonyryan1@…

There is in fact a csp.php in the test directory, however it looks severely dated to the current specification and would need updating.

In addition to this, I fear I'm skeptical that these php based test variants are actually run. It appears as though the xhtml one has been broken for a fairly long time.

If php based tests aren't the variant that's preferred right now, what is? I'd also like to point out that currently, there is no reliable way to catch CSP errors in javascript. The test written would need to be outside the scope of qUnit, and tested separately.

Let me know how you'd like to proceed and I'll come up with a test to whatever standard you're interested in.

While I'm at it, I'd also be interested in fixing the XHTML tests, as that directly affects projects I manage.

Anthony Ryan

comment:3 Changed 22 months ago by davidben

This wouldn't be a short-term solution, but I'll find the relevant WG and request a feature. There really should be better JavaScript access to CSP. At the very least it ought to be possible to query the current policy or something.

Perhaps the test could be based on report-uri somehow. There's a report-uri directive to trigger a request at a certain URL when the policy is violated. The server-side code could just keep some state and let you query it later. (If that's there, why didn't they do a DOM event too...) Asserting that this doesn't happen would likely be a bit wonky though since there's something asynchronous involved.

comment:4 Changed 22 months ago by anthonyryan1

That solution of storing a persistent state based on report-uri is already what I had in mind (and written), afraid I may not have explained it clearly.

Right now though, I have a working patch written in PHP (the language I saw already in use). I just need to know what the preferred webserver language would be (PHP, Node?), and whether cookies or flatfiles are preferred for persistent data. Whatever language is decided, would be required everywhere tests are run, so I don't want to make any assumptions.

comment:5 Changed 21 months ago by dmethvin

  • Milestone changed from 1.8 to 1.8.1

comment:6 Changed 20 months ago by dmethvin

  • Milestone changed from 1.8.1 to 1.9

comment:7 Changed 17 months ago by dmethvin

  • Milestone changed from 1.9 to None

comment:8 Changed 14 months ago by gibson042

  • Status changed from open to closed
  • Resolution set to fixed
  • Milestone changed from None to 1.9.2

comment:9 Changed 11 months ago by dmethvin

  • Milestone changed from 1.9.2 to 1.10/2.0

Bulk update to milestone 1.10/2.0

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.