redirectToPost implementation is incompatible with strict Content-Security-Policy #1647

charukiewicz · 2019-11-30T23:55:03Z

The Problem

Work working with yesod-auth I ran into a strange issue where my /auth/logout path stopped automatically redirecting me to my intended logout page, and instead left me in the intermediary "Continue" state. It turns out that this issue was caused by a Content-Security-Policy header that does not allow unsafe-inline, blocking inline JavaScript and instead throwing an error.

Turns out that this issue is caused by the current implementation of redirectToPost, which relies on an inline <script> tag.

My Attempted Solution

I tried to refactor redirectToPost, currently implemented as:

redirectToPost :: (MonadHandler m, RedirectUrl (HandlerSite m) url)
               => url
               -> m a
redirectToPost url = do
    urlText <- toTextUrl url
    req <- getRequest
    withUrlRenderer [hamlet|
$newline never
$doctype 5

<html>
    <head>
        <title>Redirecting...
    <body>
        <form id="form" method="post" action=#{urlText}>
            $maybe token <- reqToken req
                <input type=hidden name=#{defaultCsrfParamName} value=#{token}>
            <noscript>
                <p>Javascript has been disabled; please click on the button below to be redirected.
            <input type="submit" value="Continue">
        <script>
          window.onload = function() { document.getElementById('form').submit(); };
|] >>= sendResponse

My approach to eliminate the inline <script> tag was to convert the window.onload line to a widget and load it into the hamlet body. Here's what I tried to do:

redirectToPost :: (MonadHandler m, RedirectUrl (HandlerSite m) url)
               => url
               -> m a
redirectToPost url = do
    urlText <- toTextUrl url
    req <- getRequest
    pc <- widgetToPageContent $ toWidget $ [julius|window.onload = function() { document.getElementById('form').submit(); };|]
    withUrlRenderer [hamlet|
$newline never
$doctype 5

<html>
    <head>
        <title>Redirecting...
    <body>
        <form id="form" method="post" action=#{urlText}>
            $maybe token <- reqToken req
                <input type=hidden name=#{defaultCsrfParamName} value=#{token}>
            <noscript>
                <p>Javascript has been disabled; please click on the button below to be redirected.
            <input type="submit" value="Continue">
        ^{pageBody pc}
|] >>= sendResponse

I believe this approach would work, but toWidget is defined in Yesod.Core.Widget, which depends on Yesod.Core.Handler (the module with the change), so that's not really an option.

Another Possible Solution

A different solution would be to make the GET handler (getLogoutR) delete the user's credentials, with no need for this intermediary page. Currently it is implemented as:

yesod/yesod-auth/Yesod/Auth.hs

Lines 468 to 471 in 463fd54

    
           getLogoutR :: AuthHandler master () 
        
           getLogoutR = do 
        
             tp <- getRouteToParent 
        
             setUltDestReferer' >> redirectToPost (tp LogoutR)

This approach was suggested in #1475 (for reasons unrelated to a CSP), but rejected, for the reason that GET requests should not modify server state.

How to Proceed

I started my first-ever Yesod project a few months ago, and while I very much like the framework, I think one of the project's goals should be to strive for compatibility with modern web standards, especially ones related to security. A strict Content-Security-Policy is one of the examples of that. To quote Mozilla:

The use of this header is the best method to prevent cross-site scripting (XSS) vulnerabilities. Due to the difficulty in retrofitting CSP into existing websites, CSP is mandatory for all new websites and is strongly recommended for all existing high-risk sites.

I understand the argument for not making GET requests modify server state. If that isn't a good option, I am curious to hear if anyone else has thoughts on the approach I outlined above (relying on making the automatic redirect a widget rather than an inline <script>), or if anyone has any thoughts on this issue in general.

The text was updated successfully, but these errors were encountered:

snoyberg · 2019-12-03T05:56:16Z

I don't think Widgets can be relied upon to solve this problem. They may also inject the Javascript into a script tag. Though I suppose you could argue that, if someone enabled that header, then they better also fix the rendering of Javascript to be in a separate file.

So I guess I'm OK with moving to the Widget approach.

Idea for implementation: what if we make a new method in the Yesod typeclass for this, and have redirectToPost call that. Then we can provide a method for people to opt-in to the new behavior if they want.

jezen · 2019-12-11T19:25:55Z

@charukiewicz I actually struggled with the same earlier, but it was merged already here: #1620

I wrote more about working with a CSP in Yesod, which you can read here: https://jezenthomas.com/implementing-csp-in-yesod/

You might find it useful.

charukiewicz · 2019-12-17T03:49:36Z

@jezen Thanks for the link and suggesting this approach. This is very helpful. Looks like using a strict-dynamic CSP solves the problem I described in my first post.

jezen · 2019-12-17T09:21:41Z

I think that given your immediate issue is resolved, this thread can be closed.

I do agree with your point here:

I think one of the project's goals should be to strive for compatibility with modern web standards, especially ones related to security. A strict Content-Security-Policy is one of the examples of that.

But I think this is a separate (and much larger) conversation to be had.

charukiewicz changed the title ~~yesod-core redirectToPost implementation is incompatible with strict Content-Security-Policy~~ redirectToPost implementation is incompatible with strict Content-Security-Policy Nov 30, 2019

jezen closed this as completed Dec 17, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

redirectToPost implementation is incompatible with strict Content-Security-Policy #1647

redirectToPost implementation is incompatible with strict Content-Security-Policy #1647

charukiewicz commented Nov 30, 2019 •

edited

Loading

snoyberg commented Dec 3, 2019

jezen commented Dec 11, 2019 •

edited

Loading

charukiewicz commented Dec 17, 2019 •

edited

Loading

jezen commented Dec 17, 2019

redirectToPost implementation is incompatible with strict Content-Security-Policy #1647

redirectToPost implementation is incompatible with strict Content-Security-Policy #1647

Comments

charukiewicz commented Nov 30, 2019 • edited Loading

The Problem

My Attempted Solution

Another Possible Solution

How to Proceed

snoyberg commented Dec 3, 2019

jezen commented Dec 11, 2019 • edited Loading

charukiewicz commented Dec 17, 2019 • edited Loading

jezen commented Dec 17, 2019

charukiewicz commented Nov 30, 2019 •

edited

Loading

jezen commented Dec 11, 2019 •

edited

Loading

charukiewicz commented Dec 17, 2019 •

edited

Loading