Podcast Detail

SANS Stormcast Wednesday, February 25th, 2026: Open Redirects; setHTML in Firefox; telnetd issues

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9824.mp3

previous
Podcast Logo
Open Redirects; setHTML in Firefox; telnetd issues
00:00

Podcast Transcript

 Hello and welcome to the Wednesday, February 25th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ulrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu graduate certificate program in cloud
 security. One thing I noticed today was that our honeypots
 have been seeing recently a big increase in the number of
 scans looking for open redirects. An open redirect is
 a feature in a web application where the web application
 redirects you to another site without any regard as to where
 the user is really being redirected to. And it often
 happens as per login pages where you would like to, for
 example, direct a user to the page they originally attempted
 to visit. And well, also click through counters and similar
 features that often use redirects and with that are
 susceptible to creating open redirects. There are a couple
 of problems with open redirects. So open redirects
 is basically a redirect where you're not really filtering
 what page you're redirecting the user to. The receiving
 page may then, for example, receive URL parameters, but
 could also be used for phishing. One spot where this
 has been particularly a little bit of problem lately is with
 OAuth 2 where during the initial credential flow where
 you are authorizing a site to use a particular service.
 Well, the site is being redirected back to the client
 that's attempting to use these credentials. But if an
 attacker is able to swap that redirect URI for a URI that is
 vulnerable for an open redirect, the attacker may
 obtain credentials. And that sort of bypasses some of the
 protections that sites have put in place to prevent these
 changes of the redirect URI. So it's certainly an important
 vulnerability. It's not currently sort of part of the
 OWASP top 10, but OWASP has a great sort of cheat sheet
 about open redirects and how to prevent them and why they
 are a problem. Also interesting here, pretty much
 all of the requests that sort of responsible for that peak
 over the last few days, they came from one IP address
 associated with IP volume. IP volume is often referred to as
 a bulletproof hoster, meaning that they're not really all
 that eager to follow up on abuse requests and are often
 providing shelter to some illegal activity. So you may
 want to take a look at whether or not it's appropriate for
 you to block their AS. And talking a little bit about web
 application security, we do have an interesting new
 development here from Mozilla, from the Firefox team, and
 that's support for SetHTML. SetHTML is part of the
 sanitizer API, and that's a standard that's supposed to
 make it easier to prevent some cross-site scripting attacks.
 In particular, so some of these DOM-based cross-site
 scripting attacks that have been particularly difficult to
 sort of prevent in some modern applications. The problem here
 is that we often use JavaScript in order to insert
 unsanitized text into an HTML page, and then of course you
 are opening yourself up for cross-site scripting. What the
 sanitizer API in SetHTML does is that it basically doesn't
 allow you to insert unsafe HTML, and that's in particular
 anything that's related to JavaScript. It comes with a
 default configuration that's pretty good, but you can
 basically define also your own configuration and which
 particular HTML tags and attributes you are allowing.
 Pretty easy standard to implement in my opinion, and
 it sort of tries to basically balance the two ends we had so
 far. We had innerHTML, which of course was horribly unsafe,
 and that led to a lot of these problems. We had innerText,
 which didn't allow any HTML at all. So with SetHTML you still
 are able to use markup, just no JavaScript. There's also
 the idea of trusted types that's also supported. SetHTML
 at this point in the SantaHaser API appears to be
 only supported in Firefox and Chrome. So Safari is still
 holding out here. Haven't really found anything quickly
 sort of when Safari, if Safari is going to implement this.
 Once I think Safari does, then this becomes a real usable
 standard to actually integrate in your web applications. You
 know how it sometimes goes if there's a vulnerability in a
 particular piece of software. We then have people look
 closer and find additional vulnerabilities. There's a
 second pretty bad and interesting telnetd
 vulnerability. Remember we had like a couple months ago the
 one with the dash F, where basically command line
 parameters were easily passed to the login shell. And then
 you could essentially bypass authentication. This second
 one isn't quite as bad. It's really more approach
 escalation vulnerability. But the root cause here is that
 Telnet also is able to set environment variables. And
 some environment variables can be used for authentication. In
 particular one pointed out here in the bug report by Ron
 Ben Yizhak is the credentials directory. Credentials
 directory is basically where you find credentials. And if
 an attacker is able to create a file essentially anywhere on
 the system, they're then able to log in as any user,
 including root. So that's the problem here. Pretty
 interesting vulnerability as I said. The workaround,
 apparently some versions of Telnet have implemented this.
 But the workaround here is that you only allow very
 specific environment variables to be set. There are couples
 that are useful like no language and things like that
 and encoding parameters and such that are useful and that
 Telnet does routinely set. And the solution is to just limit
 it to these specific environment variables.
 Apparently others have just basically set up block lists
 of environment variables they don't allow. And then of
 course, people just come up with a different way to set
 the same environment variable or another environment
 variable that they may have missed that some systems are
 using. Well, and that's it for today. Thanks for listening.
 Thanks for liking. Thanks for subscribing. And special
 thanks to anybody leaving a good comment with your
 favorite podcast platform. And talk to you again tomorrow.
 Bye.