In this episode we talk about the spell check feature of the browser and how it could present a risk to sensitive data.
Listen to the Episode:
Link to article referenced: https://www.darkreading.com/application-security/spellchecking-google-chrome-microsoft-edge-browsers-leaks-passwords
For more info go to https://www.developsec.com or follow us on twitter (@developsec).
On this episode James talks about the spellcheck feature of browsers and how it relates to sensitive data.
Tackling the challenge to integrate security into the development process, looking for insights, answers and practical solutions to avoid getting overwhelmed. Welcome to the develop SEC podcast where our focus is your success in securing and improving development processes. And here’s your host, James Jardine.
Hey, everyone, welcome back to the show. Welcome to the new year. It’s been a little while since I’ve done some recording on the podcast. But now that we’re fresh in 2023, looking to take an opportunity to bring some more topics back start getting back into this little bit.
So I hope you are looking forward to joining me on the journey of identifying some more application security, product security, secure development topics, to help you kind of build your programs, and hopefully in the end, really just start building more secure applications from the start. So that’s where a lot of our focus is going to be on as it always has, I think we’re going to also dive a little bit into the leadership side of things as well. I think it’s important for us to understand how development plays a role in building secure applications. And when I say development, that obviously doesn’t mean just developers, it means QA, that means business analysts, project managers. So we’re gonna have a lot of content coming out. So keep your eye on that stuff.
Today, I want to take a look at something I actually saw this a couple of months ago, I was going through my draft blog posts, and I saw it and I was like, Oh, I never really posted this. So I want to go back and take a look at it.
So back, I guess around September of last year, some researchers had come out with some information about the spellcheck feature within the browsers. And the ability for that to actually leak some sensitive info depending on the configuration you might have within your browser. So for example, if in Chrome, you had enhanced spell checking capabilities turned on, which are not turned on by default I’m pretty sure, it was possible that some sensitive information might be being sent to the Google servers to be able to perform the spell checking. So this is kind of an interesting scenario. I mean, at first, you might think, well, it’s Google servers, you know, they’re just using it for the spellcheck feature, maybe it’s not that big of a risk. But anytime we’re taking information from our application and sending it to another application, we don’t control or another service. Obviously, that creates some level of risk for us. And we want to make sure we’re protecting against that.
Now, this to me is kind of similar to the idea of caching, right. And for a long time, we talked about oh, we have to turn caching off for sensitive fields when we send stuff back down to the browser. So if I’ve got social security numbers, or credit card numbers, things like that, we always say turn off the caching. So that way, it doesn’t get cached in the local browser, and somebody else couldn’t come along later on, and then try to view that data. Oftentimes, though, we’ll just turn it off of the entire page. How many times have you had a pen test on or you’ve had some scanning done, and it comes back and tells you Oh, you have to disable caching, but this header in here, but this metadata in here, will turn caching off. So similar to that, right, we’re looking for sensitive fields to make sure that we’re not taking maybe usernames considered sensitive field password, obviously, would be considered a sensitive field, social security numbers, private information, we want to make sure that we’re not sending that back out to other servers that we don’t control.
And in this case, we’re talking about the spellcheck area, to be able to make sure that we’re not sending information out to spell checking services. And this is interesting, because I didn’t even I didn’t realize this either, until this article came out, I’ll put a link to the article in the show notes. Until that came out. I never even really gave any thought to the spellcheck feature or the browser or even how anything really happens around those input fields when they’re sitting in the browser. So we want to make sure that we understand this stuff. So we can set the appropriate things.
It’s kind of like the autocomplete when we went back. And we always said, Hey, on the password field, make sure you’re turning autocomplete off. So that way, the browser’s not storing this information. This is another one of those layers, where we’re saying, hey, let’s make sure that the browser’s not doing something with that data that we don’t understand. So it’s less about what it’s doing with it. And really more about us as developers as testers, understanding what the browser’s doing so we can make sure that we take control over the aspects that we have control of, there are lots of things we can’t control. This is one of those things.
Now, unlike caching, where maybe we turned off at the whole page, typically we’re not doing that spellcheck actually is a pretty useful feature. So we don’t want to just turn it off for everything, maybe we want notes fields, or other things like that, where we want spell checking capabilities to be there. So because of that, we don’t want to just turn it off everywhere. Really, we want to kind of be like a sniper in this aspect of okay, what fields do we want to turn it off for? So of course, that starts with identifying what are your sensitive fields, right? That could be your social security numbers, it could be credit card numbers, it could be something, HIPAA related, you know, PCI related, you pick it, whatever sensitive to you, maybe you username some places, usernames are considered sensitive fields, some places they’re not a random username with nothing else around it. No other context is just a string of data doesn’t really have anything to do with anything. So that may or may not be considered sensitive data.
One interesting caveat to this is that the password field from a spell check perspective, the password field isn’t really kind of vulnerable to this issue. Unless, unless you actually have a show password feature, right? Where it unmasks it and shows you what that password is. At that point, if somebody unmasked the data, then it will run it through the spell checker, in certain circumstances, not always. But if you have like the enhanced spell checking, experienced or not, it’ll run it through the spell checker. And then now all of a sudden the password has been sent across.
Now, again, I haven’t looked super in depth on how the browser sends these over if it’s per field, if it’s per form. If it’s per field, then a password going across for spell checking, without any other context. Now, of course, they have context, because every request has IP address and some of these other details, who knows what else they’re grabbing from your browser. But theoretically, out of context, this is a string of characters, that doesn’t mean anything. But in that case, if you’re doing something with a show password, we might want to turn spellcheck off for those specific fields, to make sure that that data is not being sent out when we don’t need it. And to be honest, a lot of these fields where we would turn spellcheck off, probably don’t really benefit from spellcheck. I mean, a Username field, probably not that much, I’m not gonna benefit that much from a spell check on a Password field. Well, if you’re creating passwords, that are random and all this different stuff, spellcheck should work on them anyway. So no benefit there.
Social security numbers, when there’s really nothing spellcheck there, because that’s a pre formatted string. You know, if there’s stuff like that, really, there’s no benefit for the spellcheck on those fields. So it’s okay to turn that off, right, versus if I have a field where I want spell checking to happen. Maybe its name fields, addresses that type of stuff, notes fields, well, then obviously want to keep spellcheck on. But we’re not too concerned about the sensitivity of that data, to the same regards that we are about more highly sensitive data that might be out there. So we have the option to be able to turn this off. And we can do it at three different levels, we can do it at the input box level, we can do it at the text area level. And we can also do it at the forum level if you want to turn it off for the entire form.
And the way we do it on all three cases, is each of those HTML elements, we’re just going to add in a spell check equals false attribute. And that will turn it off for that field. So pretty simple stuff to be able to add this in and make sure that we’re not doing spell checking in those scenarios. So now that we know that this is a potential issue, and we know how we can go through and fix it, the other last question really that we have is, how do we verify that we’re doing it and the first step to verifying that we’re going to fix this, or that we have fixed this is knowing which of those fields we need to do so maybe this drops back into data classification, and understanding that if we have certain fields listed under certain classification types, maybe something’s confidential, maybe it’s top secret, however you do your confidentiality types or classification types, being able to specify on there and say, Okay, this field, spellcheck has to be off. You know, same thing with password field spell autocorrect has to be autocomplete has to be off for that.
This always goes back to defining good requirements and good design, to upfront be able to specify here’s the types of data that we’re going to use. Here’s the risks around those different types of data. Here’s the protections that we’re going to put around that data. And then once we have all that defined, then when we go to develop it, we know, we need to make sure that we add this piece in there. When we go to test it, we know we want to validate that, yes, spellcheck is turned off on these certain fields. That type of stuff is easy to validate once we actually define it. But so often we don’t define him. And in my mind, the first step in all of this is this step right here, which is actually just realizing that exists, I had no idea about the ability to turn spellcheck on or off within the browser. Now, it’s been a while since I’ve done development.
So I don’t know every attribute that’s available and all the different elements, but just raising the awareness of the fact that that attributes there and that we can control this is going to be very helpful in thinking about that as we go through it as you’re building up your next form, thinking, Oh, this is a social security number, should I turn this value off? What do I need to do to make sure that we’re protecting this as we should be protecting it? So that’s pretty much it. Pretty simple concept, just something I hadn’t seen before. So I thought it’d be really fun to kind of share out with everybody. I’m not sure how many others have not seen this before. So if this is new to you, hopefully you find it kind of interesting. I thought it was pretty neat when I saw it.
So like I said, I’ll link to the article, it’s a good way to kind of kick the year off something short, simple. Start talking about security from a different aspect. Like I said, we’ll have a bunch more coming out this year. Really getting back into trying to get some more episodes out here. If there’s stuff that you’re interested in, please feel free to send me a line. You can reach me at James at develop sec.com. And always happy to see your feedback. If you’ve got certain topics or anything like that, send them my way. Otherwise, I’ll be sending some more information your way. Again, I’d like to thank you for listening to the show. Hope you had a good 2022 And I’m looking forward to spending 2023 sharing some more content with everybody. So thanks for listening, and have a great day.
You have been listening to the develop tech podcast with James Jardine. To find out more about how we can help you with application security. Follow us on Twitter @developsec or check out our website at www.developsec.com
Leave a Reply
You must be logged in to post a comment.