January 30, 2026 • 18 mins
Ever read a security advisory that told you to “use a VPN” to protect a Bluetooth device?
In this episode we talk about how bad or inaccurate recommendations can be a problem with security findings. We take a look at an example of recommendations that don't relate to the issue at all, leaving people confused at how to respond.
Share with us your experience with recommendations that just missed the mark.
References:
CISA Wheelchair Article - https://www.cisa.gov/news-events/ics-medical-advisories/icsma-25-364-01
Skateboard Article - https://gizmodo.com/faceplant-exploit-lets-hackers-hijack-an-electric-ska-1722691650
Bicycle Shifter Article - https://www.bicycling.com/racing/a61994540/hackers-target-electronic-shifters/
For more info go to https://www.developsec.com or follow us on X (@developsec).
The DevelopSec podcast is brought to you by Jardine Software Inc.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:04):
On this episode, we talk about the importance of having relevant,accurate recommendations for your security findings.
Tackling the challenge to integrate security into the development process.
Looking for insights, answers and practical solutions to avoid gettingoverwhelmed. Welcome to the DevelopSec podcast, where our
(00:30):
focus is your success in securing and improving developmentprocesses. And here is your host,
James Jardine. Hey everyone.
Welcome to this episode of the DevelopSec podcast. TodayI wanted to talk about security
recommendations and when I mean securityrecommendations, I'm talking about when you have a pen test done
(00:54):
or even automated scans that exist within your systems ortools. All of these, when they find something,
are going to give some sort of recommendation to the developmentteam, to whoever might actually fix this. Maybe it's not a developer
thing, maybe it's infrastructure, but we've gotten a lot better over the yearsof having better recommendations outside of just
(01:16):
outputting coding or something simple like that.
We've gotten a lot more detailed and we try to reallycater to those recommendations, to the situation at
hand. I spent a lot of years doing penetrationtesting, offensive security, writing reports
for the findings that we see, reviewing reportsthat come from the different tools or from different vendors for testing,
(01:43):
and working with development teams to try to help make sure thatthe information that there is helpful and they don't have to spend a
lot of time trying to figure out, okay, how do I implement this? You'vesaid something is broken or the logic's not right, but
now I have to figure out how do I go ahead and resolve this. Andwhen the recommendations aren't clear, it causes
(02:05):
confusion. It really kind of creates a big issue. Andthe reason I started thinking about this was I was
reading through my normal morning news feeds andI stumbled across a CISA
ICS medical advisory.
And basically what this was, some people had found somevulnerabilities in a specific model of
(02:31):
electric wheelchairs. And so with this, it waspossible these electric wheelchairs have some sort of
Bluetooth connectivity or some near fieldcommunication that could be taken advantage of. There was missing
authentication for, they call it missing authentication forcritical function. And basically it allowed somebody that
(02:53):
was within range, typically from aBluetooth. Maybe you're talking 6 or 10 meters for common range,
within range, somebody couldbypass the authentication and be able to control
this wheelchair, which, I mean,that could be concerning depending on where you are. I mean, there's
(03:16):
definitely a risk around this. And I won't go too deep intothe actual vulnerabilities and the risks around that,
but this was an interesting thing to start looking at wheelchairs. We'veSeen also in the past. There was a story
a while back talking, and this was actually 2015.
(03:38):
And I'll put a link to this story as well, just for reference.
Title of it is hackers can hijack electric skateboards Now.
And this was something where some of these electric skateboards have a controller on them.
It's Bluetooth connected. The Bluetooth pairing doesn't haveauthentication on it, or there's no encryption on it, and
somebody within range could actually control the skateboard. Theyactually called it, I think Faceplant was the name of their
(04:05):
exploit. And you know, they say inthere, imagine you're going 20 miles an hour on this skateboard and then all of
a sudden somebody else locks the brakes up on it. So I mean, there's arisk, obviously with this, It's a, it's a physical presence risk. It's not over the
Internet. This is something, somebody has to be close enough to take advantage ofthe Bluetooth that exists. There was also another story, and
(04:26):
this is actually more recent. Let me see if this actually tells mewhen it. Well, okay, so this is 2024, that
they came out with a way. And I didn't know this, apparently onbicycles or some of the higher end cycling
rigs out there for pro cyclists, they have electronicshifters that also run through like a Bluetooth
(04:51):
setting. And some researchers found out there wasa way to replay commands to those
systems. I think they actually cite 10 meters in there. But, you know, ifyou're within 10, maybe even 15
meters enough where the signal would get picked up,you could actually cause the gears to shift on the bicycle.
(05:12):
Now, these things, some of them I kind of find comical. We putit out there as this end of the world situation,
but typically it's really not sure. I mean, you could messwith somebody shifting gears, but you got to be close enough to them. And
somebody that's riding pro cycles, probably riding 25,30 miles an hour. So if you're standing still, you get a very small
(05:35):
window to capture and replay these commands. But there isrisk. I won't deny that there's risk around that. But in
all these situations, and these ones are similar,we want to understand, okay, so how do I resolve this? If I go back
to the gear shifter manufacturer, you know, what am Itelling people? How we can resolve this? And what could you do to mitigate
(05:57):
this to protect yourself? If you have one of these, these shifters or ifyou have this wheelchair or if you have that skateboard?
Oftentimes, especially with these, it's a communication issue. So we got toupdate how we're doing our Bluetooth authentication, making
sure that we protect against replay attacks. There's not a lotthe user can really do in these
(06:19):
situations but wait for firmware updateand then apply that patch to our system and that'll protect us.
And so really what got me with thisadvisory when I saw it was around the recommendations
and they kind of threw me for a little bit because theyweren't really relevant. They were almost kind of generic recommendations.
(06:41):
I'll read a couple of these off to share what they were. Now,again, keep in mind this is some sort of
Bluetooth, I'm assuming, connection that's beingtaken advantage of in this case to be able to take control over this system.
Again, most of the part you're waiting for a patchfrom the creator to be able to update the firmware
(07:04):
or somehow get an update to it.
So that way it'll remove this unauthenticatedcapability to perform these actions. Their
list of items on there starts withto really mitigate this problem, they start
talking about how you want tominimize network exposure for all
(07:30):
control system devices and or systems ensuring they are notaccessible from the Internet. So right
there is kind of this first interesting what are we talkingabout? Because this isn't a
network connected system or at least it's not beingtaken advantage of that way. This is being taken advantage of because somebody's
(07:52):
accessing Bluetooth. So reducingthis network exposure from the Internet really isn't
relevant. The next one is locate control systemnetworks and remote devices behind firewalls and isolating
them from business networks. It's a wheelchair out inthe public or at your home. It's not on a business network. Again, it's
(08:14):
Bluetooth. The recommendationdoesn't really do anything in this case. I don't know how you put a firewall
around your wheelchair or if we were to apply this to theskateboard or the shifter. I don't know if we're going to start seeing people riding
around in wheelchairs looking like bubble boy out there with a bubble aroundtheir thing to block any external connections to
(08:36):
protect against somebody that could connect through Bluetooth and start controlling theirdevice. Then the final one that they had
is their prime recommendations. And these aredefensive measures to minimize the risk of exploitation
is when remote access is required. Use more securemethods such as VPNs. Recognizing
(08:59):
VPNs may have vulnerabilities and should be updated to the most current version available.
I don't know how you connect to your wheelchairor other bluetooth devices through a vpn. Maybe
that technology exists. I haven't seen it. But again,it feels irrelevant to what we're really
(09:20):
trying to address, that the issue is here.
And then we also go on to. They have some other steps torecommend users take following measures to protect themselves
from social engineering attacks. Talking about, do not click onweb links or open attachments and unsolicited email messages.
(09:41):
So those are the recommendations, but when you take a step back, they don'tmatch the issue at all. These are
just generic recommendations that you can't even apply. They don't even existfor this situation. And that, I think,
is where we start seeing confusion amongst people because nowthey're thinking, oh, how do I do this? How do I go find a
(10:04):
way to set up a VPN between my phoneand the wheelchair device? How do I
disconnect it from the Internet? How do I do these other things whenin the end there's no way to do it and if there was, it so
wouldn't have solved the problem. Now, I do want to be clear. They did. Thecompany did issue patches to help resolve this and mitigate these issues
(10:26):
fairly quickly, it looks like. But the focus hereisn't on the risks that exist. We can say there's definitely
risks to these situations. All of these, even though some of themare somewhat comical when you think about it, you know, I'm going to
wipe somebody out on their skateboard. Sure, there's true risk to that,but it's still kind of funny to think about. But
(10:50):
it's the recommendations, I think, that matter. And this iswhere I see the difference between the
good security teams and the onesthat are just kind of getting by. You get a lot of people that'll
just take these recommendations, like, oh, here's the generic recommendations forthis. It looks close. Let me just throw these on here and I'll throw it
(11:12):
back over the fence. We see this problem, even with bug bounties,different things where the reports aren't that great. Even professional
pen test firms sometimes don't give the bestadvice for resolving the issue. And
I think we've struggled with this on the security side for a while. And it'seasy to identify flaws and some of these things are harder. I
(11:35):
won't diminish the work to find some of these things. Some are verynovel, but they are. It's easier to
show what the problem is sometimes than it is to say how to fixit. Especially with a lot of these systems, the person finding the issue
may not have the insights into how that system actuallyworks. When we're doing pen tests, we
(12:00):
often don't have the source code. We don't know exactly what that code lookslike. We're guessing sometimes that, hey, you could do it this way,
or a common best practicewould be this. But I don't know if that works in your
context. So there's a challenge there.
There's no doubt there's a challenge there, but we want to make surewe're taking that time to try to dig in and get the right information
(12:28):
because it builds the trust. And for me,in application security, when I'm talking with developers, I want them to trust
that I know what I'm talking about and that if I'm giving you arecommendation and it's somewhat detailed at times
that I know what I'm talking about, this will work for your situation, or it'llbe pretty close. And I've saved you a bunch of time. You don't have
(12:50):
to go dig into it a whole lot. And again, we can't always do that.
But I don't want you to think that I just pulled something upbecause I saw it someplace and threw it over. And then when you go to
implement it, it doesn't fit your narrative, it doesn't work with yourplatform. It's a completely different thing. I'm not giving you a Ruby
on Rails example of how to resolve something whenyou're programming in. NET and it's irrelevant. I'm not
(13:17):
telling you about using reference maps, whichis something I'd see in a Java app. When you're using.
Net, which doesn't have those natively built in, it'sa matter of building up that rapport and showing, hey, I understand what
you're going through. I have that empathy. I did the legwork to try tohelp build up what I'm going to send to you, and when I send is
(13:39):
going to be good. And you build that trust betweeneach other, that you trust that the findings are real, you
don't have to second guess them. You trust that the information coming acrossis good, you don't have to second guess it. It's starting you on the
right path. But when we start seeing things that arejust blatantly way off base, we start
(14:02):
breaking down that trust. And now questionsstart appearing, oh, is this vulnerability real? Now I have to
go out and verify it myself. I have to recreate it to prove it, becauseI'm not sure if you were wrong here, how do I know you're not wrong
over there? So I Think it's important that wetry to emphasize getting those
(14:23):
things right. And I think from the development side, whenyou're receiving reports back and you're getting recommendations in there,
have that open dialogue. Keep in mind that wedon't see from the offensive side, everything
necessarily that you see. Sometimes we're making guessesand we've had. I've seen plenty of findings on reports that
(14:47):
what looks like an issue to the tester, you gettalking to the development team or the product owner and
you start to understand no, wait, it's actually supposed to work like that. Andnow having more context, it makes sense so
we adjust accordingly. Same thing with the recommendations.
Maybe the, the default, I want to say generic, but thedefault recommendation pushes towards a certain
(15:13):
thing. But had I known you havethis in place, maybe that pushes me to take
it a step further. Oh, you have a WAF in place. Okay, wellmaybe there's a recommendation we can make for the WAF to help mitigate while you're
waiting. But that's not the full mitigation. Let's also include.
We want to make sure we're doing output encoding here orparameterization of your SQL queries over here.
(15:39):
It's building up and making sure we have the best information possible.
So I just wanted to just share that this came out actuallya little bit ago, probably a month or a month and a half ago.
I think when I saw this first report, I just been thinking about it torecord it and I just think it's interesting
to see the different things. I mean last one of the other episodes wetalked about the importance of terminology and using the right
(16:05):
terms in certain areas. And I think this ties directly with that ofthe importance of having accurate information
both in the vulnerability and in the remediation orrecommendation steps to have as
complete of the information that we can have out there.
So I hope you found this interesting AgainI'll share the links to those three different
(16:31):
pages, the web pages talking about the shifters, the, thewheelchair and the skateboard if anybody's interested to go back and check
those out. It is kind of interesting to see the differentthings people come up with to what they can
do from a hacking standpoint. And I think it's helpful froma developer standpoint to see that too because while you might not have the skateboard,
(16:53):
you might not have that wheelchairor the sifters, you might be a developer that's out there working
on some sort of OT device or thesetypes of devices. And maybe you didn't think about
the communication channel through the Bluetooth of things beingreplayed or tampered with. Intercepted
(17:16):
authentication, these kind of like the old days of mobile apps, we didn'treally think a lot about the authentication because we, it was kind of
hidden from our view. Same thing here. A lot of people,they're not seeing these different hacks that happen
and I think when we see them, it helps us better understandif we have to program against it. Oh yeah, I remember
(17:39):
there was an issue where somebody did this. Let me make sure I'm covering that.
And that's really the point is raising that awareness andgetting you to understand some of the different risks that affect different areas.
So if you ever have to work in those, they're kind of backof mind and you're just thinking, okay, I got to protect against
this. So I'll put the links in there. I appreciate everybody listening andI look forward to the next episode.
(18:10):
You have been listening to the DevelopSec podcast with JamesJarvine to find out more about how we can help you with
application security. Follow us on Twittervelopsec or check out our website at
www.developsec.com.
On this episode, we talk about the importance of having relevant,accurate recommendations for your security findings.
Tackling the challenge to integrate security into the development process.
Looking for insights, answers and practical solutions to avoid gettingoverwhelmed. Welcome to the DevelopSec podcast, where our
(00:30):
focus is your success in securing and improving developmentprocesses. And here is your host,
James Jardine. Hey everyone.
Welcome to this episode of the DevelopSec podcast. TodayI wanted to talk about security
recommendations and when I mean securityrecommendations, I'm talking about when you have a pen test done
(00:54):
or even automated scans that exist within your systems ortools. All of these, when they find something,
are going to give some sort of recommendation to the developmentteam, to whoever might actually fix this. Maybe it's not a developer
thing, maybe it's infrastructure, but we've gotten a lot better over the yearsof having better recommendations outside of just
(01:16):
outputting coding or something simple like that.
We've gotten a lot more detailed and we try to reallycater to those recommendations, to the situation at
hand. I spent a lot of years doing penetrationtesting, offensive security, writing reports
for the findings that we see, reviewing reportsthat come from the different tools or from different vendors for testing,
(01:43):
and working with development teams to try to help make sure thatthe information that there is helpful and they don't have to spend a
lot of time trying to figure out, okay, how do I implement this? You'vesaid something is broken or the logic's not right, but
now I have to figure out how do I go ahead and resolve this. Andwhen the recommendations aren't clear, it causes
(02:05):
confusion. It really kind of creates a big issue. Andthe reason I started thinking about this was I was
reading through my normal morning news feeds andI stumbled across a CISA
ICS medical advisory.
And basically what this was, some people had found somevulnerabilities in a specific model of
(02:31):
electric wheelchairs. And so with this, it waspossible these electric wheelchairs have some sort of
Bluetooth connectivity or some near fieldcommunication that could be taken advantage of. There was missing
authentication for, they call it missing authentication forcritical function. And basically it allowed somebody that
(02:53):
was within range, typically from aBluetooth. Maybe you're talking 6 or 10 meters for common range,
within range, somebody couldbypass the authentication and be able to control
this wheelchair, which, I mean,that could be concerning depending on where you are. I mean, there's
(03:16):
definitely a risk around this. And I won't go too deep intothe actual vulnerabilities and the risks around that,
but this was an interesting thing to start looking at wheelchairs. We'veSeen also in the past. There was a story
a while back talking, and this was actually 2015.
(03:38):
And I'll put a link to this story as well, just for reference.
Title of it is hackers can hijack electric skateboards Now.
And this was something where some of these electric skateboards have a controller on them.
It's Bluetooth connected. The Bluetooth pairing doesn't haveauthentication on it, or there's no encryption on it, and
somebody within range could actually control the skateboard. Theyactually called it, I think Faceplant was the name of their
(04:05):
exploit. And you know, they say inthere, imagine you're going 20 miles an hour on this skateboard and then all of
a sudden somebody else locks the brakes up on it. So I mean, there's arisk, obviously with this, It's a, it's a physical presence risk. It's not over the
Internet. This is something, somebody has to be close enough to take advantage ofthe Bluetooth that exists. There was also another story, and
(04:26):
this is actually more recent. Let me see if this actually tells mewhen it. Well, okay, so this is 2024, that
they came out with a way. And I didn't know this, apparently onbicycles or some of the higher end cycling
rigs out there for pro cyclists, they have electronicshifters that also run through like a Bluetooth
(04:51):
setting. And some researchers found out there wasa way to replay commands to those
systems. I think they actually cite 10 meters in there. But, you know, ifyou're within 10, maybe even 15
meters enough where the signal would get picked up,you could actually cause the gears to shift on the bicycle.
(05:12):
Now, these things, some of them I kind of find comical. We putit out there as this end of the world situation,
but typically it's really not sure. I mean, you could messwith somebody shifting gears, but you got to be close enough to them. And
somebody that's riding pro cycles, probably riding 25,30 miles an hour. So if you're standing still, you get a very small
(05:35):
window to capture and replay these commands. But there isrisk. I won't deny that there's risk around that. But in
all these situations, and these ones are similar,we want to understand, okay, so how do I resolve this? If I go back
to the gear shifter manufacturer, you know, what am Itelling people? How we can resolve this? And what could you do to mitigate
(05:57):
this to protect yourself? If you have one of these, these shifters or ifyou have this wheelchair or if you have that skateboard?
Oftentimes, especially with these, it's a communication issue. So we got toupdate how we're doing our Bluetooth authentication, making
sure that we protect against replay attacks. There's not a lotthe user can really do in these
(06:19):
situations but wait for firmware updateand then apply that patch to our system and that'll protect us.
And so really what got me with thisadvisory when I saw it was around the recommendations
and they kind of threw me for a little bit because theyweren't really relevant. They were almost kind of generic recommendations.
(06:41):
I'll read a couple of these off to share what they were. Now,again, keep in mind this is some sort of
Bluetooth, I'm assuming, connection that's beingtaken advantage of in this case to be able to take control over this system.
Again, most of the part you're waiting for a patchfrom the creator to be able to update the firmware
(07:04):
or somehow get an update to it.
So that way it'll remove this unauthenticatedcapability to perform these actions. Their
list of items on there starts withto really mitigate this problem, they start
talking about how you want tominimize network exposure for all
(07:30):
control system devices and or systems ensuring they are notaccessible from the Internet. So right
there is kind of this first interesting what are we talkingabout? Because this isn't a
network connected system or at least it's not beingtaken advantage of that way. This is being taken advantage of because somebody's
(07:52):
accessing Bluetooth. So reducingthis network exposure from the Internet really isn't
relevant. The next one is locate control systemnetworks and remote devices behind firewalls and isolating
them from business networks. It's a wheelchair out inthe public or at your home. It's not on a business network. Again, it's
(08:14):
Bluetooth. The recommendationdoesn't really do anything in this case. I don't know how you put a firewall
around your wheelchair or if we were to apply this to theskateboard or the shifter. I don't know if we're going to start seeing people riding
around in wheelchairs looking like bubble boy out there with a bubble aroundtheir thing to block any external connections to
(08:36):
protect against somebody that could connect through Bluetooth and start controlling theirdevice. Then the final one that they had
is their prime recommendations. And these aredefensive measures to minimize the risk of exploitation
is when remote access is required. Use more securemethods such as VPNs. Recognizing
(08:59):
VPNs may have vulnerabilities and should be updated to the most current version available.
I don't know how you connect to your wheelchairor other bluetooth devices through a vpn. Maybe
that technology exists. I haven't seen it. But again,it feels irrelevant to what we're really
(09:20):
trying to address, that the issue is here.
And then we also go on to. They have some other steps torecommend users take following measures to protect themselves
from social engineering attacks. Talking about, do not click onweb links or open attachments and unsolicited email messages.
(09:41):
So those are the recommendations, but when you take a step back, they don'tmatch the issue at all. These are
just generic recommendations that you can't even apply. They don't even existfor this situation. And that, I think,
is where we start seeing confusion amongst people because nowthey're thinking, oh, how do I do this? How do I go find a
(10:04):
way to set up a VPN between my phoneand the wheelchair device? How do I
disconnect it from the Internet? How do I do these other things whenin the end there's no way to do it and if there was, it so
wouldn't have solved the problem. Now, I do want to be clear. They did. Thecompany did issue patches to help resolve this and mitigate these issues
(10:26):
fairly quickly, it looks like. But the focus hereisn't on the risks that exist. We can say there's definitely
risks to these situations. All of these, even though some of themare somewhat comical when you think about it, you know, I'm going to
wipe somebody out on their skateboard. Sure, there's true risk to that,but it's still kind of funny to think about. But
(10:50):
it's the recommendations, I think, that matter. And this iswhere I see the difference between the
good security teams and the onesthat are just kind of getting by. You get a lot of people that'll
just take these recommendations, like, oh, here's the generic recommendations forthis. It looks close. Let me just throw these on here and I'll throw it
(11:12):
back over the fence. We see this problem, even with bug bounties,different things where the reports aren't that great. Even professional
pen test firms sometimes don't give the bestadvice for resolving the issue. And
I think we've struggled with this on the security side for a while. And it'seasy to identify flaws and some of these things are harder. I
(11:35):
won't diminish the work to find some of these things. Some are verynovel, but they are. It's easier to
show what the problem is sometimes than it is to say how to fixit. Especially with a lot of these systems, the person finding the issue
may not have the insights into how that system actuallyworks. When we're doing pen tests, we
(12:00):
often don't have the source code. We don't know exactly what that code lookslike. We're guessing sometimes that, hey, you could do it this way,
or a common best practicewould be this. But I don't know if that works in your
context. So there's a challenge there.
There's no doubt there's a challenge there, but we want to make surewe're taking that time to try to dig in and get the right information
(12:28):
because it builds the trust. And for me,in application security, when I'm talking with developers, I want them to trust
that I know what I'm talking about and that if I'm giving you arecommendation and it's somewhat detailed at times
that I know what I'm talking about, this will work for your situation, or it'llbe pretty close. And I've saved you a bunch of time. You don't have
(12:50):
to go dig into it a whole lot. And again, we can't always do that.
But I don't want you to think that I just pulled something upbecause I saw it someplace and threw it over. And then when you go to
implement it, it doesn't fit your narrative, it doesn't work with yourplatform. It's a completely different thing. I'm not giving you a Ruby
on Rails example of how to resolve something whenyou're programming in. NET and it's irrelevant. I'm not
(13:17):
telling you about using reference maps, whichis something I'd see in a Java app. When you're using.
Net, which doesn't have those natively built in, it'sa matter of building up that rapport and showing, hey, I understand what
you're going through. I have that empathy. I did the legwork to try tohelp build up what I'm going to send to you, and when I send is
(13:39):
going to be good. And you build that trust betweeneach other, that you trust that the findings are real, you
don't have to second guess them. You trust that the information coming acrossis good, you don't have to second guess it. It's starting you on the
right path. But when we start seeing things that arejust blatantly way off base, we start
(14:02):
breaking down that trust. And now questionsstart appearing, oh, is this vulnerability real? Now I have to
go out and verify it myself. I have to recreate it to prove it, becauseI'm not sure if you were wrong here, how do I know you're not wrong
over there? So I Think it's important that wetry to emphasize getting those
(14:23):
things right. And I think from the development side, whenyou're receiving reports back and you're getting recommendations in there,
have that open dialogue. Keep in mind that wedon't see from the offensive side, everything
necessarily that you see. Sometimes we're making guessesand we've had. I've seen plenty of findings on reports that
(14:47):
what looks like an issue to the tester, you gettalking to the development team or the product owner and
you start to understand no, wait, it's actually supposed to work like that. Andnow having more context, it makes sense so
we adjust accordingly. Same thing with the recommendations.
Maybe the, the default, I want to say generic, but thedefault recommendation pushes towards a certain
(15:13):
thing. But had I known you havethis in place, maybe that pushes me to take
it a step further. Oh, you have a WAF in place. Okay, wellmaybe there's a recommendation we can make for the WAF to help mitigate while you're
waiting. But that's not the full mitigation. Let's also include.
We want to make sure we're doing output encoding here orparameterization of your SQL queries over here.
(15:39):
It's building up and making sure we have the best information possible.
So I just wanted to just share that this came out actuallya little bit ago, probably a month or a month and a half ago.
I think when I saw this first report, I just been thinking about it torecord it and I just think it's interesting
to see the different things. I mean last one of the other episodes wetalked about the importance of terminology and using the right
(16:05):
terms in certain areas. And I think this ties directly with that ofthe importance of having accurate information
both in the vulnerability and in the remediation orrecommendation steps to have as
complete of the information that we can have out there.
So I hope you found this interesting AgainI'll share the links to those three different
(16:31):
pages, the web pages talking about the shifters, the, thewheelchair and the skateboard if anybody's interested to go back and check
those out. It is kind of interesting to see the differentthings people come up with to what they can
do from a hacking standpoint. And I think it's helpful froma developer standpoint to see that too because while you might not have the skateboard,
(16:53):
you might not have that wheelchairor the sifters, you might be a developer that's out there working
on some sort of OT device or thesetypes of devices. And maybe you didn't think about
the communication channel through the Bluetooth of things beingreplayed or tampered with. Intercepted
(17:16):
authentication, these kind of like the old days of mobile apps, we didn'treally think a lot about the authentication because we, it was kind of
hidden from our view. Same thing here. A lot of people,they're not seeing these different hacks that happen
and I think when we see them, it helps us better understandif we have to program against it. Oh yeah, I remember
(17:39):
there was an issue where somebody did this. Let me make sure I'm covering that.
And that's really the point is raising that awareness andgetting you to understand some of the different risks that affect different areas.
So if you ever have to work in those, they're kind of backof mind and you're just thinking, okay, I got to protect against
this. So I'll put the links in there. I appreciate everybody listening andI look forward to the next episode.
(18:10):
You have been listening to the DevelopSec podcast with JamesJarvine to find out more about how we can help you with
application security. Follow us on Twittervelopsec or check out our website at
www.developsec.com.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Betrayal Season 5
Saskia Inwood woke up one morning, knowing her life would never be the same. The night before, she learned the unimaginable – that the husband she knew in the light of day was a different person after dark. This season unpacks Saskia’s discovery of her husband’s secret life and her fight to bring him to justice. Along the way, we expose a crime that is just coming to light. This is also a story about the myth of the “perfect victim:” who gets believed, who gets doubted, and why. We follow Saskia as she works to reclaim her body, her voice, and her life. If you would like to reach out to the Betrayal Team, email us at betrayalpod@gmail.com. Follow us on Instagram @betrayalpod and @glasspodcasts. Please join our Substack for additional exclusive content, curated book recommendations, and community discussions. Sign up FREE by clicking this link Beyond Betrayal Substack. Join our community dedicated to truth, resilience, and healing. Your voice matters! Be a part of our Betrayal journey on Substack.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com