Welcome to the Patchstack Weekly Security Update, Episode 45! This update is for week 43 of 2022.
Last week’s news included a new WordPress security release. WordPress 6.0.3 was made publicly available on Monday October 17th. You can read a summary of the WordPress 6.0.3 release on the Patchstack blog, or stay tuned for this week’s vulnerability roundup where I will provide a very fast breakdown of all 16 of the bugs patched in WordPress 6.0.3.
One of the more interesting security bugs patched in WordPress 6.0.3 addressed an open redirect concern. In this week’s knowledge share I will be discussing what an open redirect security bug is, what risks it poses, and how developers can patch them if they’re found in their code base.
What is an open redirect security bug?
Open redirect security bugs are caused when a web application’s code can be tricked into redirecting a visitor to a URL of an attacker’s choosing.
There are many URL shortening services that have the sole purpose of redirecting a visitor to another URL. So why is an open redirect such a big deal?
For starters, most people recognize links that start with tinyurl.com or t.co (for Twitter) as redirect services. Users may recognize these domain names and know when they click a link it will redirect them elsewhere, it is expected behavior. Also, these URL-shrinking services have dedicated teams and detection methods implemented to prevent abuse of their services.
The risk of open redirects has to do with phishing, or tricking users to enter credentials on a malicious website. The fact that it looks like you’re on your own domain makes this even more of a concern. If you see a link to your own website and click on it, then you see a WordPress login prompt. You might think “Oh, this is my website I guess I should log in” and enter your credentials before noticing your browser was redirected to an entirely different domain name.
Phishing becomes a little more likely to succeed in the above scenario – not guaranteed, but more likely. But, even if phishing is not a worry to you let’s be honest: Unless your web application was intended to provide URL redirects as a service (like bitly or tinyurl) you probably shouldn’t be providing redirects as an unintentional service.
How to prevent open redirects?
As with most security bugs, open redirects boil down to user-controlled values being trusted when they shouldn’t be and result in redirecting the browser to a URL controlled outside of the application.
If your application has a valid reason to send a browser a redirect, then you have two choices. Enforce an allow list or hard code the domain or URI, there are slight differences between the two.
1. Make an allow list
An allow list would be useful if you can make a list of allowable URIs or domain names you would like the application to redirect the browser to.
You will of course need to regularly maintain this list in your code so you should include documentation or a proper error message like “Redirect URI not allowed” in case you need to add more approved URIs in the future.
2. Hard-code the domain or URI
If you wish to be even more restrictive you can hard-code or use a constant or function (like site_url() in WordPress) to ensure the domain you are redirecting to is the same as the web application.
Even better, simply never send user-supplied values into any function or call which could lead to redirecting the browser.
Where do redirects happen in code?
There are many places a redirect can be set up in a web application code base. Here are a few examples:
HTTP header redirect
The HTTP headers can be set in either the web application (PHP) or on the web server. If you open OWASP ZAP or your browser’s developer tools you can spot a redirect as a response with a response code of 300-399 (aka 3xx) when you inspect that HTTP response’s headers you will find a “Location” value which is where the browser gets redirected to.
Location: https://redirected/to/URIIn PHP, this Location header can be sent to the response headers via the header() function. This is the function you would look for to ensure no user-controlled inputs are being sent to.
HTML redirect
Redirects can happen right in the HTML too!
An example HTML redirect can be added using a <meta> tag within the <head> block.
<meta http-equiv="refresh" content="0; URL=https://redirected/to/URI">Javascript redirect
Javascript can even be used to redirect the browser elsewhere.
It is as simple as setting the window.location to another URI.
window.location = "https://redirected/to/URI"There may be more locations for redirects in a web application. All you need to remember as a developer is that whenever you intend to redirect the browser to another URI, you should never trust user input, use a hard-coded value or use an allow list to prevent against open redirect security bugs.
Vulnerability roundup
In this week’s vulnerability roundup, I will be summarizing the WordPress 6.0.3 security release’s bug list.
WordPress 6.0.3 Security Release
Overall the 6.0.3 release contained 16 security bug patches and is of medium severity, as this is the highest severity of all of the bugs patched.
The bug with the highest severity rating (5.3 CVSS score) was a data exposure in the REST API bug found and reported by Than Taintor. This bug could allow details such as the tag or terms values of unpublished posts to be read by unauthenticated users.
Next highest severity (4.3 CVSS) was an eight-way tie of mostly XSS, CSRF, and the open redirect in WordPress before 6.0.3 bug which was patched.
The remaining seven security bugs patched are all low severity CVSS ratings. The lower severity rating is due to the difficulty to exploit in the wild and low impact if successful. They include more XSS, one unlikely SQL injection, and two security bugs related to wp-mail.php which only affect WordPress websites with “Post via email” enabled.
What we can learn from this is that the WordPress security team put in a lot of work toward this release and they (as well as the researchers who reported these bugs) deserve some appreciation.
Thanks and appreciation
This week’s thanks goes out to everyone involved in the WordPress 6.0.3 security release. In total there were at least 28 WordPress developers and 11 security researchers (and one security audit firm) involved in this security release. On behalf of the hundreds of millions of websites that rely on WordPress, I thank you for making the project more secure.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!
