[wp-trac] [WordPress Trac] #43308: Alter behavior load-scripts.php and load-styles.php to reduce potentially adverse scenarios (was: Require authentication for load-scripts.php and load-styles.php)

[WordPress Trac]

#43308: Alter behavior load-scripts.php and load-styles.php to reduce potentially
adverse scenarios
---------------------------+------------------------------
 Reporter:  youngcp        |       Owner:
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Script Loader  |     Version:  4.9.4
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:
---------------------------+------------------------------

Comment (by youngcp):

 Replying to [comment:4 Clorith]:

 WAFs mitigate cachable requests, but there's too many non-cached
 combinations that can be invited by this thing. Fail2ban works ok, but it
 puts the stressers on; banning entire institutions due to a single
 compromised source is not good. Neither are good alternatives.

 > The patch should adhere to the [https://make.wordpress.org/core/handbook
 /best-practices/coding-standards/ WordPress coding standards], that's a
 bit besides the point, but nice to just mention and get out of the way
 right off the bat.

 Is there a common IDE configuration file somewhere, e.g. for phpStorm,
 vim, some linters?

 > Now, your solution in this patch is to just include `wp-
 admin/admin.php`, this does two things;
 > - It sends a nocache header (there's a not-modified code in `load-
 scripts.php` to reduce repeat requests for legitimate users)
 > - It forced you to be logged in

 I think I can address both of these in short order.
 I see where the no-cache is in code, don't see a no-cache header being
 sent (I see cache-control: public, max-age=31536000) - I assume it's being
 overwritten?

 > This second point creates an awkward situation, as some themes and
 plugins use this file to concatenate scripts on the front end for visitors
 as well. This is a consideration we need to account for that may lead to
 broken sites if we implement something with just authentication
 requirements.

 It's already "hold my beer," but let's see what we can do about
 controlling non-authenticated access and allowing the result to be cached.
 Nonces prevent caching, so any variation of is straight out. Anything that
 generates a lot of potential URL patterns for the same request is out.

 So there needs to be a no-cache interstitial that can't be hammered at
 load-scripts and load-styles with a cache-friendly redirect that takes a
 generated key (maybe a hash) that combines the unique load request and
 some validation salt to prevent guessing (easy enough). I think I can do
 that.

 Replying to [comment:5 azaozz]:

 I think I can accommodate you, but the white-list is significantly large.
 Loading WordPress a third time takes less total time than it took for
 loading the entire white-list.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43308#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform