pimschaaf

Payload
action	"dismiss_admin_notice"
option_name	"disable-notice-warning-comments"
dismissible_length	"forever"
nonce	"46550356b0"

Response headers
HTTP/2 403
date: Fri, 19 Jan 2024 12:22:54 GMT
server: Apache/2
access-control-allow-origin: [private]
access-control-allow-credentials: true
x-robots-tag: noindex
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
x-frame-options: SAMEORIGIN
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-cache, must-revalidate, max-age=0, no-store, private
x-ua-compatible: IE=edge
vary: Accept-Encoding,User-Agent
content-encoding: gzip
content-length: 23
content-type: text/html; charset=UTF-8
X-Firefox-Spdy: h2

Request headers
POST /wp-admin/admin-ajax.php HTTP/2
Host: [private]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0
Accept: */*
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: [private]
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 121
Origin: [private]
Connection: keep-alive
Cookie: wordpress_sec
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

On the latest 1.9.13 version I get a 403 on the request to wp-admin.
I’ve tried putting Wordfence in learning mode with no effect.

Making database changes to remove this, is not a viable option with the amounts of sites I manage.

Thanks for following up on this.

• This reply was modified 1 year, 2 months ago by pimschaaf. Reason: added payload

Hi Peter,

Posting back to confirm that things work in Learning Mode and continue to be good after Optimizing the Firewall and disabling Learning Mode. The issue is solved.

I’m not sure why this didn’t work after the full reset, which I think would have re-enabled learning mode as well.
Out of interest: shouldn’t these URLs then show up under the Allowlisted URLs section?

I’ve also lowered the max_execution_time. Thanks for describing issue that might cause.

Thank you very much for your help.

Hi Peter,
Thanks for your quick and in depth response. I’ll post back tomorrow as soon as I’ve tested your suggestions.

This issue persist, provided fix works.

When is this fix scheduled for release?

It appears this has been fixed in Safe SVG 2.0.0

With wpscan.com now reporting security issues in <1.9.10 it is becoming an urgent issue for me that no upgrade is available with the above fixed.

Public proof of concept for that security issue is landing in 8 days..
See https://wpscan.com/plugin/safe-svg

@dkotter thanks for the quick follow-up. I’ve tested the PR locally and found it to fix the issue I have posted above.

Same here with theme from scratch using plain wp_get_attachment_image($image_id, 'custom_image_size', false).

For the following SVG the output has changed.

<svg xmlns="https://www.w3.org/2000/svg" width="68" height="70" viewBox="0 0 68 70"></svg>

Using 1.9.9 this outputs <img src="example-path/file.svg" loading="lazy" height="70" width="68" />

Using 1.9.10 this outputs <img width="1024" height="9999" src="example-path/file.svg" />

Where 1024 and 9999 correspond with add_image_size( 'custom_image_size', 1024, 9999 );.

I see the order of attributes also has changed, the width/height attributes are now before src and loading attributes (which might help to identify the problem).

Let me know if you need more information to reproduce this issue.

• This reply was modified 3 years ago by pimschaaf.
• This reply was modified 3 years ago by pimschaaf.
• This reply was modified 3 years ago by pimschaaf.

Replace the following:

if($_GET['preview_offline']==true){ return false; }

with:

if(isset($_GET['preview_offline']) && $_GET['preview_offline']==true){ return false; }

on super-simple-site-offline-beta/functions/rights.php:11

It works in Twentytwentyone, so there’s more going on in the RealEstate 7 theme (or the child theme customizations that have been made to RE7 in my project) that might be the root cause of this issue.

Yes, jQuery Nice Select is hiding the entire original select element and replacing it. It shouldn’t matter as the ‘fake’ select should trigger all events on the original select.

That said, there will be a double .ics-calendar-select in the DOM, which might mess with assumptions (if any have been made) in using jQuery’s next(), prev() etc.. Issues like that might be preventable in ICS Calendar. Again, I don’t think that is the issue here.

Keep up the good work!

Further testing points in the direction of a compatibility issue with jQuery Nice Select as implemented in Real Estate 7 theme.

Changing wp-content\plugins\ics-calendar\assets\script.js:292 from

jQuery('.ics-calendar.layout-month .ics-calendar-select').trigger('change');

to

jQuery('.ics-calendar.layout-month .ics-calendar-select:not(.nice-select)').trigger('change');

fixes the loading display by preventing the Nice Select duplicated ‘nice’ select box from triggering the change event for the second time on page load.

• I cannot reproduce the issue in a minimal setup based on TwentyTwentyOne child theme with jQuery Nice Select. The duplicated select box does not trigger another change event there.
• I am not quite sure which mechanism in the ICS Calendar change handler would hide the first displayed month when it is triggered. This might be something you could help out with.
• I haven’t yet been able to find why this issue emerges in the RealEstate 7 theme.

In the end I think this is an issue for the theme developer to resolve, but I’ll keep this issue open for a little bit in case you would have any hints that could help point anyone in the right direction.

Thanks!

• This reply was modified 3 years, 4 months ago by pimschaaf.

Thanks for your response. I could imagine it is something specific to this site and you having had no problems like it indeed suggest the same.

I’ll try to make a reduced example and post that here as soon as I have time.

It might help if you could elaborate on the logic of those two/three lines (290-292) of JS code, what is their exact purpose?

Thanks!

Perfect, that hook should help us out here. I can see why this workaround might not be universally applicable.

To be clear, Chrome claims it to be redirect loop. I’m not sure what it is being redirected to, but given the workaround I think that wp_logout() is ultimately the mechanism for the looping behavior here.

My theory: if the bad hash is not reset properly with wp_logout(), and wp_logout() triggers a new page load, and validate() triggers on that page load with the bad hash still present it will trigger wp_logout() again, in a loop.

Thanks!

This problem persists in 3.9.7. The same fix works.

Thanks guys. Never quite got around to writing that pull request. Great to see it added! Keep up the good work!