Does someone need to be connected to my network to sniff HTTP requests?Without SSL, what vantage point does one need to MITM non-SSL'd HTTP?Burp proxy between non proxy aware devicewireshark does't show HTTP requests from other devicesARP spoofing on WLAN: seeing only traffic coming backHow is this “captive portal” intercepting and manipulating my HTTP requests?Tracking down Malware within home networkWhy are there open ports on my home network router?Replay attack in Wi-Fi (802.11) networkHow is my employer accessing my router when employer's laptop is wirelessly connected to my home networkMonitoring connected hosts in a network via hub and wireshark
Interplanetary conflict, some disease destroys the ability to understand or appreciate music
What did Alexander Pope mean by "Expletives their feeble Aid do join"?
Are all passive ability checks floors for active ability checks?
how to write formula in word in latex
The difference between「N分で」and「後N分で」
Existence of subset with given Hausdorff dimension
How to write cleanly even if my character uses expletive language?
Does someone need to be connected to my network to sniff HTTP requests?
Do I need life insurance if I can cover my own funeral costs?
How do I hide Chekhov's Gun?
How to simplify this time periods definition interface?
Why do Australian milk farmers need to protest supermarkets' milk price?
How to terminate ping <dest> &
How Could an Airship Be Repaired Mid-Flight
What approach do we need to follow for projects without a test environment?
Why would a flight no longer considered airworthy be redirected like this?
How to read the value of this capacitor?
Most cost effective thermostat setting: consistent temperature vs. lowest temperature possible
What has been your most complicated TikZ drawing?
What are substitutions for coconut in curry?
Why doesn't using two cd commands in bash script execute the second command?
Error in Twin Prime Conjecture
Look at your watch and tell me what time is it. vs Look at your watch and tell me what time it is
In a future war, an old lady is trying to raise a boy but one of the weapons has made everyone deaf
Does someone need to be connected to my network to sniff HTTP requests?
Without SSL, what vantage point does one need to MITM non-SSL'd HTTP?Burp proxy between non proxy aware devicewireshark does't show HTTP requests from other devicesARP spoofing on WLAN: seeing only traffic coming backHow is this “captive portal” intercepting and manipulating my HTTP requests?Tracking down Malware within home networkWhy are there open ports on my home network router?Replay attack in Wi-Fi (802.11) networkHow is my employer accessing my router when employer's laptop is wirelessly connected to my home networkMonitoring connected hosts in a network via hub and wireshark
TL;DR Would a potential attacker need to have my Wi-Fi password and be connected to my network in order to read HTTP requests?
Over the past year or so, I have made a few DIY home automation projects. Included in this is a garage door opener. The basic premise of which is that when I want to open the garage, the home automation hub sends an http
(not https
) GET
request (e.g. 192.168.1.xxx/openGarage
) to the DIY IoT device which then opens the garage. (The IoT device will trigger the garage whenever it receives that specific /openGarage
request)
However, for some time now, this has worried me. I was wondering whether an attacker who was not connected to the network would be able to intercept the HTTP get request (192.168.1.xxx/openGarage
) and then be able to replay this get request in order to open the garage without my knowing.
So, my question is: would an attacker need to be connected to my home network in order to intercept this GET
request (/openGarage
) or would they need to bee connected in order to see this?
Thank you in advance for your help,
Kind regards, Rocco
P.S. I understand that making this request an https
one instead would obfuscate the request, however, it is quite hard to implement proper SSL encryption on an ESP8266 which is what I am using for this IoT device. Thus, I am willing to hinge my security on the strength of my WPA2 password. That is, if an attacker would need to be connected to my network in the first place to intercept the request as per the above question.
network wifi http sniffing
add a comment |
TL;DR Would a potential attacker need to have my Wi-Fi password and be connected to my network in order to read HTTP requests?
Over the past year or so, I have made a few DIY home automation projects. Included in this is a garage door opener. The basic premise of which is that when I want to open the garage, the home automation hub sends an http
(not https
) GET
request (e.g. 192.168.1.xxx/openGarage
) to the DIY IoT device which then opens the garage. (The IoT device will trigger the garage whenever it receives that specific /openGarage
request)
However, for some time now, this has worried me. I was wondering whether an attacker who was not connected to the network would be able to intercept the HTTP get request (192.168.1.xxx/openGarage
) and then be able to replay this get request in order to open the garage without my knowing.
So, my question is: would an attacker need to be connected to my home network in order to intercept this GET
request (/openGarage
) or would they need to bee connected in order to see this?
Thank you in advance for your help,
Kind regards, Rocco
P.S. I understand that making this request an https
one instead would obfuscate the request, however, it is quite hard to implement proper SSL encryption on an ESP8266 which is what I am using for this IoT device. Thus, I am willing to hinge my security on the strength of my WPA2 password. That is, if an attacker would need to be connected to my network in the first place to intercept the request as per the above question.
network wifi http sniffing
add a comment |
TL;DR Would a potential attacker need to have my Wi-Fi password and be connected to my network in order to read HTTP requests?
Over the past year or so, I have made a few DIY home automation projects. Included in this is a garage door opener. The basic premise of which is that when I want to open the garage, the home automation hub sends an http
(not https
) GET
request (e.g. 192.168.1.xxx/openGarage
) to the DIY IoT device which then opens the garage. (The IoT device will trigger the garage whenever it receives that specific /openGarage
request)
However, for some time now, this has worried me. I was wondering whether an attacker who was not connected to the network would be able to intercept the HTTP get request (192.168.1.xxx/openGarage
) and then be able to replay this get request in order to open the garage without my knowing.
So, my question is: would an attacker need to be connected to my home network in order to intercept this GET
request (/openGarage
) or would they need to bee connected in order to see this?
Thank you in advance for your help,
Kind regards, Rocco
P.S. I understand that making this request an https
one instead would obfuscate the request, however, it is quite hard to implement proper SSL encryption on an ESP8266 which is what I am using for this IoT device. Thus, I am willing to hinge my security on the strength of my WPA2 password. That is, if an attacker would need to be connected to my network in the first place to intercept the request as per the above question.
network wifi http sniffing
TL;DR Would a potential attacker need to have my Wi-Fi password and be connected to my network in order to read HTTP requests?
Over the past year or so, I have made a few DIY home automation projects. Included in this is a garage door opener. The basic premise of which is that when I want to open the garage, the home automation hub sends an http
(not https
) GET
request (e.g. 192.168.1.xxx/openGarage
) to the DIY IoT device which then opens the garage. (The IoT device will trigger the garage whenever it receives that specific /openGarage
request)
However, for some time now, this has worried me. I was wondering whether an attacker who was not connected to the network would be able to intercept the HTTP get request (192.168.1.xxx/openGarage
) and then be able to replay this get request in order to open the garage without my knowing.
So, my question is: would an attacker need to be connected to my home network in order to intercept this GET
request (/openGarage
) or would they need to bee connected in order to see this?
Thank you in advance for your help,
Kind regards, Rocco
P.S. I understand that making this request an https
one instead would obfuscate the request, however, it is quite hard to implement proper SSL encryption on an ESP8266 which is what I am using for this IoT device. Thus, I am willing to hinge my security on the strength of my WPA2 password. That is, if an attacker would need to be connected to my network in the first place to intercept the request as per the above question.
network wifi http sniffing
network wifi http sniffing
asked 6 hours ago
RoccoRocco
385
385
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Yes. An attacker would need to be on your network - either wirelessly or wired - to intercept an intra-network HTTP request. If it left your network for the broader Internet, the attacker could potentially intercept it anywhere between your property and the server, but with the server on the same local network the traffic won't leave your router. As WPA provides both encryption and replay protection, an attacker wouldn't know what message you are sending, nor would they be able to replay it (although traffic analysis - such as noting the packet size, and/or noting that a message for a particular MAC address is always sent before the garage door opens - would be possible).
However, by implementing your system this way, you're opening yourself up to the massive world of web application / web service security vulnerabilities. As a trivial example, you service right now is almost certainly vulnerable to CSRF; if any machine on your network visits a web page with 256 invisible image tags on it - one each from <img src="http://192.168.1.0/openGarage">
to <img src="http://192.168.1.255/openGarage">
- your garage door would open. JS could be used to iterate through even much larger spaces very quickly.
Thank you for your answer! I'm glad to hear that an attacker would need to actually be on my network to read or replay these HTTP requests. However, as you say, I do agree that this current implementation is in no way secure. I hadn't even considered the trivial attack you mentioned. Luckily, as a first line of defence, the/openGarage
is just for demonstration and in reality the string is random generated. However, I appreciate that it is still rather insecure. What would you recommend is the best step forward? Looking intohttps
? Basic http authentication? Thanks once again!
– Rocco
5 hours ago
Basic auth wont do anything to defend in a HTTP environment. Your only hope (if HTTPS truly cant be done) is to validate the client using either a pre-shared-key or a challenge. While this would also fix the CSRF CBHacking mentioned, i think the argument of CSRF, though technically correct, is tenuous, as it insinuates someone has already figured out the /openGarage request on the network. Which would likely mean that have some level of access to your network anyway and could therefore make the request themself (that or they have read this question).
– hiburn8
5 hours ago
Neither of those approaches would fix the problem, as CSRF is entirely independent of HTTPS (or its lack) and basic auth is sent automatically by any browser that has logged into the site in question. Moving from GET to POST would make things marginally trickier but is no real fix either. Using some other HTTP verb would be much more secure, but specifically because browsers would refuse to send the request absent specific situations. I suggest an access token in a POST message body; a browser will happily send that but an attacker won't know the token to send.
– CBHacking
5 hours ago
1
@hiburn8 I will try to look further into HTTPS as I feel it will fix many unforeseen problems. Luckily, as I stated,/openGarage
specifically is just an example, in reality the string is something random (e.g./gnexewjow
) so I hope this also adds some 'security'. However, as I said in my main question, I am willing to hinge some of my security simply on the exclusivity of my network and therefore on my WPA2 passcode.
– Rocco
5 hours ago
@CBHacking Ah I see. What do you mean by "Using some other HTTP verb"? Also how do you suggest an access token would solve the problem? Would you be able to link to a more detailed explanation of the implementation? Thanks once again
– Rocco
5 hours ago
|
show 1 more comment
Unless you want to read around the subject areas involved, this is a simple question with a simple answer. YES, an attacker would need to be connected to your network (given that it is an encrypted network) in order to see the contents of packets and therefor the /openGarage API.
If thats all you care about, we're done. But I will go on to say that even in a non secured (http) environment, it might still be possible to get some level of assurance that no-one is successfully hitting up your API. The way i would do this is have a pre-shared key between the IOT device and server, which are used to generate continuously changing tokens for use to validate each-other. Essentially the same model as a one-time passcode. This seems like something even very basic IoT devices which might struggle to process HTTPS data should be able to achieve. The ideal scenario would be that the 'server' is aware of the last used token, to prevent an attacker from abusing the race-condition to re-use a token.
Pretty much any other attempt to add security would have to rely on obscurity. As a really awful example, you could change '/openGarage' to '/questions' and on that network use a DNS server such that requests appear to be going to 'stackexchange.com/questions'. Depending on what the attacker sees, they might be fooled into thinking the endpoint is of no interest/value.
Lastly. If the IoT device can handle it... some logging never hurts.
Apologies for repeating some of what CBHacking wrote, i think we were both typing at the same time. The CSRF he mentioned is remediated by the concept of a one-time passcode however... as i mentioned you could use.
– hiburn8
5 hours ago
Thank you for your detailed answer. Would you be able to go into more depth about using a pre-shared key? If it is possible, would you be able to link to a demonstration if such an implementation do I can look into seeing whether it is something I could implement into the ESP8266?
– Rocco
5 hours ago
Based on your hardware limitations, i would imagine the best tradeoff for security and effort (given that you are not protecting the crown jewels but still want to have some assurance) would be to use the current time of the devices to encrypt a string/passphrase. The 'server' would perform this operation once at timed intervals (say per minute) and therefore the client would be able to generate a valid token within this timeframe assuming it's system clock is in reasonably good sync with the server.
– hiburn8
5 hours ago
So i think to make that happen all you really need to do is A) make sure that the clocks/times are in sync for the client and server. B) figure out which forms of encryption are possible on your IoT device. Given that you are only performing encrypt actions every minute and decrypt actions on every request, this shouldnt be a huge performance requirement at all.
– hiburn8
5 hours ago
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f205466%2fdoes-someone-need-to-be-connected-to-my-network-to-sniff-http-requests%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes. An attacker would need to be on your network - either wirelessly or wired - to intercept an intra-network HTTP request. If it left your network for the broader Internet, the attacker could potentially intercept it anywhere between your property and the server, but with the server on the same local network the traffic won't leave your router. As WPA provides both encryption and replay protection, an attacker wouldn't know what message you are sending, nor would they be able to replay it (although traffic analysis - such as noting the packet size, and/or noting that a message for a particular MAC address is always sent before the garage door opens - would be possible).
However, by implementing your system this way, you're opening yourself up to the massive world of web application / web service security vulnerabilities. As a trivial example, you service right now is almost certainly vulnerable to CSRF; if any machine on your network visits a web page with 256 invisible image tags on it - one each from <img src="http://192.168.1.0/openGarage">
to <img src="http://192.168.1.255/openGarage">
- your garage door would open. JS could be used to iterate through even much larger spaces very quickly.
Thank you for your answer! I'm glad to hear that an attacker would need to actually be on my network to read or replay these HTTP requests. However, as you say, I do agree that this current implementation is in no way secure. I hadn't even considered the trivial attack you mentioned. Luckily, as a first line of defence, the/openGarage
is just for demonstration and in reality the string is random generated. However, I appreciate that it is still rather insecure. What would you recommend is the best step forward? Looking intohttps
? Basic http authentication? Thanks once again!
– Rocco
5 hours ago
Basic auth wont do anything to defend in a HTTP environment. Your only hope (if HTTPS truly cant be done) is to validate the client using either a pre-shared-key or a challenge. While this would also fix the CSRF CBHacking mentioned, i think the argument of CSRF, though technically correct, is tenuous, as it insinuates someone has already figured out the /openGarage request on the network. Which would likely mean that have some level of access to your network anyway and could therefore make the request themself (that or they have read this question).
– hiburn8
5 hours ago
Neither of those approaches would fix the problem, as CSRF is entirely independent of HTTPS (or its lack) and basic auth is sent automatically by any browser that has logged into the site in question. Moving from GET to POST would make things marginally trickier but is no real fix either. Using some other HTTP verb would be much more secure, but specifically because browsers would refuse to send the request absent specific situations. I suggest an access token in a POST message body; a browser will happily send that but an attacker won't know the token to send.
– CBHacking
5 hours ago
1
@hiburn8 I will try to look further into HTTPS as I feel it will fix many unforeseen problems. Luckily, as I stated,/openGarage
specifically is just an example, in reality the string is something random (e.g./gnexewjow
) so I hope this also adds some 'security'. However, as I said in my main question, I am willing to hinge some of my security simply on the exclusivity of my network and therefore on my WPA2 passcode.
– Rocco
5 hours ago
@CBHacking Ah I see. What do you mean by "Using some other HTTP verb"? Also how do you suggest an access token would solve the problem? Would you be able to link to a more detailed explanation of the implementation? Thanks once again
– Rocco
5 hours ago
|
show 1 more comment
Yes. An attacker would need to be on your network - either wirelessly or wired - to intercept an intra-network HTTP request. If it left your network for the broader Internet, the attacker could potentially intercept it anywhere between your property and the server, but with the server on the same local network the traffic won't leave your router. As WPA provides both encryption and replay protection, an attacker wouldn't know what message you are sending, nor would they be able to replay it (although traffic analysis - such as noting the packet size, and/or noting that a message for a particular MAC address is always sent before the garage door opens - would be possible).
However, by implementing your system this way, you're opening yourself up to the massive world of web application / web service security vulnerabilities. As a trivial example, you service right now is almost certainly vulnerable to CSRF; if any machine on your network visits a web page with 256 invisible image tags on it - one each from <img src="http://192.168.1.0/openGarage">
to <img src="http://192.168.1.255/openGarage">
- your garage door would open. JS could be used to iterate through even much larger spaces very quickly.
Thank you for your answer! I'm glad to hear that an attacker would need to actually be on my network to read or replay these HTTP requests. However, as you say, I do agree that this current implementation is in no way secure. I hadn't even considered the trivial attack you mentioned. Luckily, as a first line of defence, the/openGarage
is just for demonstration and in reality the string is random generated. However, I appreciate that it is still rather insecure. What would you recommend is the best step forward? Looking intohttps
? Basic http authentication? Thanks once again!
– Rocco
5 hours ago
Basic auth wont do anything to defend in a HTTP environment. Your only hope (if HTTPS truly cant be done) is to validate the client using either a pre-shared-key or a challenge. While this would also fix the CSRF CBHacking mentioned, i think the argument of CSRF, though technically correct, is tenuous, as it insinuates someone has already figured out the /openGarage request on the network. Which would likely mean that have some level of access to your network anyway and could therefore make the request themself (that or they have read this question).
– hiburn8
5 hours ago
Neither of those approaches would fix the problem, as CSRF is entirely independent of HTTPS (or its lack) and basic auth is sent automatically by any browser that has logged into the site in question. Moving from GET to POST would make things marginally trickier but is no real fix either. Using some other HTTP verb would be much more secure, but specifically because browsers would refuse to send the request absent specific situations. I suggest an access token in a POST message body; a browser will happily send that but an attacker won't know the token to send.
– CBHacking
5 hours ago
1
@hiburn8 I will try to look further into HTTPS as I feel it will fix many unforeseen problems. Luckily, as I stated,/openGarage
specifically is just an example, in reality the string is something random (e.g./gnexewjow
) so I hope this also adds some 'security'. However, as I said in my main question, I am willing to hinge some of my security simply on the exclusivity of my network and therefore on my WPA2 passcode.
– Rocco
5 hours ago
@CBHacking Ah I see. What do you mean by "Using some other HTTP verb"? Also how do you suggest an access token would solve the problem? Would you be able to link to a more detailed explanation of the implementation? Thanks once again
– Rocco
5 hours ago
|
show 1 more comment
Yes. An attacker would need to be on your network - either wirelessly or wired - to intercept an intra-network HTTP request. If it left your network for the broader Internet, the attacker could potentially intercept it anywhere between your property and the server, but with the server on the same local network the traffic won't leave your router. As WPA provides both encryption and replay protection, an attacker wouldn't know what message you are sending, nor would they be able to replay it (although traffic analysis - such as noting the packet size, and/or noting that a message for a particular MAC address is always sent before the garage door opens - would be possible).
However, by implementing your system this way, you're opening yourself up to the massive world of web application / web service security vulnerabilities. As a trivial example, you service right now is almost certainly vulnerable to CSRF; if any machine on your network visits a web page with 256 invisible image tags on it - one each from <img src="http://192.168.1.0/openGarage">
to <img src="http://192.168.1.255/openGarage">
- your garage door would open. JS could be used to iterate through even much larger spaces very quickly.
Yes. An attacker would need to be on your network - either wirelessly or wired - to intercept an intra-network HTTP request. If it left your network for the broader Internet, the attacker could potentially intercept it anywhere between your property and the server, but with the server on the same local network the traffic won't leave your router. As WPA provides both encryption and replay protection, an attacker wouldn't know what message you are sending, nor would they be able to replay it (although traffic analysis - such as noting the packet size, and/or noting that a message for a particular MAC address is always sent before the garage door opens - would be possible).
However, by implementing your system this way, you're opening yourself up to the massive world of web application / web service security vulnerabilities. As a trivial example, you service right now is almost certainly vulnerable to CSRF; if any machine on your network visits a web page with 256 invisible image tags on it - one each from <img src="http://192.168.1.0/openGarage">
to <img src="http://192.168.1.255/openGarage">
- your garage door would open. JS could be used to iterate through even much larger spaces very quickly.
answered 5 hours ago
CBHackingCBHacking
10.7k11627
10.7k11627
Thank you for your answer! I'm glad to hear that an attacker would need to actually be on my network to read or replay these HTTP requests. However, as you say, I do agree that this current implementation is in no way secure. I hadn't even considered the trivial attack you mentioned. Luckily, as a first line of defence, the/openGarage
is just for demonstration and in reality the string is random generated. However, I appreciate that it is still rather insecure. What would you recommend is the best step forward? Looking intohttps
? Basic http authentication? Thanks once again!
– Rocco
5 hours ago
Basic auth wont do anything to defend in a HTTP environment. Your only hope (if HTTPS truly cant be done) is to validate the client using either a pre-shared-key or a challenge. While this would also fix the CSRF CBHacking mentioned, i think the argument of CSRF, though technically correct, is tenuous, as it insinuates someone has already figured out the /openGarage request on the network. Which would likely mean that have some level of access to your network anyway and could therefore make the request themself (that or they have read this question).
– hiburn8
5 hours ago
Neither of those approaches would fix the problem, as CSRF is entirely independent of HTTPS (or its lack) and basic auth is sent automatically by any browser that has logged into the site in question. Moving from GET to POST would make things marginally trickier but is no real fix either. Using some other HTTP verb would be much more secure, but specifically because browsers would refuse to send the request absent specific situations. I suggest an access token in a POST message body; a browser will happily send that but an attacker won't know the token to send.
– CBHacking
5 hours ago
1
@hiburn8 I will try to look further into HTTPS as I feel it will fix many unforeseen problems. Luckily, as I stated,/openGarage
specifically is just an example, in reality the string is something random (e.g./gnexewjow
) so I hope this also adds some 'security'. However, as I said in my main question, I am willing to hinge some of my security simply on the exclusivity of my network and therefore on my WPA2 passcode.
– Rocco
5 hours ago
@CBHacking Ah I see. What do you mean by "Using some other HTTP verb"? Also how do you suggest an access token would solve the problem? Would you be able to link to a more detailed explanation of the implementation? Thanks once again
– Rocco
5 hours ago
|
show 1 more comment
Thank you for your answer! I'm glad to hear that an attacker would need to actually be on my network to read or replay these HTTP requests. However, as you say, I do agree that this current implementation is in no way secure. I hadn't even considered the trivial attack you mentioned. Luckily, as a first line of defence, the/openGarage
is just for demonstration and in reality the string is random generated. However, I appreciate that it is still rather insecure. What would you recommend is the best step forward? Looking intohttps
? Basic http authentication? Thanks once again!
– Rocco
5 hours ago
Basic auth wont do anything to defend in a HTTP environment. Your only hope (if HTTPS truly cant be done) is to validate the client using either a pre-shared-key or a challenge. While this would also fix the CSRF CBHacking mentioned, i think the argument of CSRF, though technically correct, is tenuous, as it insinuates someone has already figured out the /openGarage request on the network. Which would likely mean that have some level of access to your network anyway and could therefore make the request themself (that or they have read this question).
– hiburn8
5 hours ago
Neither of those approaches would fix the problem, as CSRF is entirely independent of HTTPS (or its lack) and basic auth is sent automatically by any browser that has logged into the site in question. Moving from GET to POST would make things marginally trickier but is no real fix either. Using some other HTTP verb would be much more secure, but specifically because browsers would refuse to send the request absent specific situations. I suggest an access token in a POST message body; a browser will happily send that but an attacker won't know the token to send.
– CBHacking
5 hours ago
1
@hiburn8 I will try to look further into HTTPS as I feel it will fix many unforeseen problems. Luckily, as I stated,/openGarage
specifically is just an example, in reality the string is something random (e.g./gnexewjow
) so I hope this also adds some 'security'. However, as I said in my main question, I am willing to hinge some of my security simply on the exclusivity of my network and therefore on my WPA2 passcode.
– Rocco
5 hours ago
@CBHacking Ah I see. What do you mean by "Using some other HTTP verb"? Also how do you suggest an access token would solve the problem? Would you be able to link to a more detailed explanation of the implementation? Thanks once again
– Rocco
5 hours ago
Thank you for your answer! I'm glad to hear that an attacker would need to actually be on my network to read or replay these HTTP requests. However, as you say, I do agree that this current implementation is in no way secure. I hadn't even considered the trivial attack you mentioned. Luckily, as a first line of defence, the
/openGarage
is just for demonstration and in reality the string is random generated. However, I appreciate that it is still rather insecure. What would you recommend is the best step forward? Looking into https
? Basic http authentication? Thanks once again!– Rocco
5 hours ago
Thank you for your answer! I'm glad to hear that an attacker would need to actually be on my network to read or replay these HTTP requests. However, as you say, I do agree that this current implementation is in no way secure. I hadn't even considered the trivial attack you mentioned. Luckily, as a first line of defence, the
/openGarage
is just for demonstration and in reality the string is random generated. However, I appreciate that it is still rather insecure. What would you recommend is the best step forward? Looking into https
? Basic http authentication? Thanks once again!– Rocco
5 hours ago
Basic auth wont do anything to defend in a HTTP environment. Your only hope (if HTTPS truly cant be done) is to validate the client using either a pre-shared-key or a challenge. While this would also fix the CSRF CBHacking mentioned, i think the argument of CSRF, though technically correct, is tenuous, as it insinuates someone has already figured out the /openGarage request on the network. Which would likely mean that have some level of access to your network anyway and could therefore make the request themself (that or they have read this question).
– hiburn8
5 hours ago
Basic auth wont do anything to defend in a HTTP environment. Your only hope (if HTTPS truly cant be done) is to validate the client using either a pre-shared-key or a challenge. While this would also fix the CSRF CBHacking mentioned, i think the argument of CSRF, though technically correct, is tenuous, as it insinuates someone has already figured out the /openGarage request on the network. Which would likely mean that have some level of access to your network anyway and could therefore make the request themself (that or they have read this question).
– hiburn8
5 hours ago
Neither of those approaches would fix the problem, as CSRF is entirely independent of HTTPS (or its lack) and basic auth is sent automatically by any browser that has logged into the site in question. Moving from GET to POST would make things marginally trickier but is no real fix either. Using some other HTTP verb would be much more secure, but specifically because browsers would refuse to send the request absent specific situations. I suggest an access token in a POST message body; a browser will happily send that but an attacker won't know the token to send.
– CBHacking
5 hours ago
Neither of those approaches would fix the problem, as CSRF is entirely independent of HTTPS (or its lack) and basic auth is sent automatically by any browser that has logged into the site in question. Moving from GET to POST would make things marginally trickier but is no real fix either. Using some other HTTP verb would be much more secure, but specifically because browsers would refuse to send the request absent specific situations. I suggest an access token in a POST message body; a browser will happily send that but an attacker won't know the token to send.
– CBHacking
5 hours ago
1
1
@hiburn8 I will try to look further into HTTPS as I feel it will fix many unforeseen problems. Luckily, as I stated,
/openGarage
specifically is just an example, in reality the string is something random (e.g. /gnexewjow
) so I hope this also adds some 'security'. However, as I said in my main question, I am willing to hinge some of my security simply on the exclusivity of my network and therefore on my WPA2 passcode.– Rocco
5 hours ago
@hiburn8 I will try to look further into HTTPS as I feel it will fix many unforeseen problems. Luckily, as I stated,
/openGarage
specifically is just an example, in reality the string is something random (e.g. /gnexewjow
) so I hope this also adds some 'security'. However, as I said in my main question, I am willing to hinge some of my security simply on the exclusivity of my network and therefore on my WPA2 passcode.– Rocco
5 hours ago
@CBHacking Ah I see. What do you mean by "Using some other HTTP verb"? Also how do you suggest an access token would solve the problem? Would you be able to link to a more detailed explanation of the implementation? Thanks once again
– Rocco
5 hours ago
@CBHacking Ah I see. What do you mean by "Using some other HTTP verb"? Also how do you suggest an access token would solve the problem? Would you be able to link to a more detailed explanation of the implementation? Thanks once again
– Rocco
5 hours ago
|
show 1 more comment
Unless you want to read around the subject areas involved, this is a simple question with a simple answer. YES, an attacker would need to be connected to your network (given that it is an encrypted network) in order to see the contents of packets and therefor the /openGarage API.
If thats all you care about, we're done. But I will go on to say that even in a non secured (http) environment, it might still be possible to get some level of assurance that no-one is successfully hitting up your API. The way i would do this is have a pre-shared key between the IOT device and server, which are used to generate continuously changing tokens for use to validate each-other. Essentially the same model as a one-time passcode. This seems like something even very basic IoT devices which might struggle to process HTTPS data should be able to achieve. The ideal scenario would be that the 'server' is aware of the last used token, to prevent an attacker from abusing the race-condition to re-use a token.
Pretty much any other attempt to add security would have to rely on obscurity. As a really awful example, you could change '/openGarage' to '/questions' and on that network use a DNS server such that requests appear to be going to 'stackexchange.com/questions'. Depending on what the attacker sees, they might be fooled into thinking the endpoint is of no interest/value.
Lastly. If the IoT device can handle it... some logging never hurts.
Apologies for repeating some of what CBHacking wrote, i think we were both typing at the same time. The CSRF he mentioned is remediated by the concept of a one-time passcode however... as i mentioned you could use.
– hiburn8
5 hours ago
Thank you for your detailed answer. Would you be able to go into more depth about using a pre-shared key? If it is possible, would you be able to link to a demonstration if such an implementation do I can look into seeing whether it is something I could implement into the ESP8266?
– Rocco
5 hours ago
Based on your hardware limitations, i would imagine the best tradeoff for security and effort (given that you are not protecting the crown jewels but still want to have some assurance) would be to use the current time of the devices to encrypt a string/passphrase. The 'server' would perform this operation once at timed intervals (say per minute) and therefore the client would be able to generate a valid token within this timeframe assuming it's system clock is in reasonably good sync with the server.
– hiburn8
5 hours ago
So i think to make that happen all you really need to do is A) make sure that the clocks/times are in sync for the client and server. B) figure out which forms of encryption are possible on your IoT device. Given that you are only performing encrypt actions every minute and decrypt actions on every request, this shouldnt be a huge performance requirement at all.
– hiburn8
5 hours ago
add a comment |
Unless you want to read around the subject areas involved, this is a simple question with a simple answer. YES, an attacker would need to be connected to your network (given that it is an encrypted network) in order to see the contents of packets and therefor the /openGarage API.
If thats all you care about, we're done. But I will go on to say that even in a non secured (http) environment, it might still be possible to get some level of assurance that no-one is successfully hitting up your API. The way i would do this is have a pre-shared key between the IOT device and server, which are used to generate continuously changing tokens for use to validate each-other. Essentially the same model as a one-time passcode. This seems like something even very basic IoT devices which might struggle to process HTTPS data should be able to achieve. The ideal scenario would be that the 'server' is aware of the last used token, to prevent an attacker from abusing the race-condition to re-use a token.
Pretty much any other attempt to add security would have to rely on obscurity. As a really awful example, you could change '/openGarage' to '/questions' and on that network use a DNS server such that requests appear to be going to 'stackexchange.com/questions'. Depending on what the attacker sees, they might be fooled into thinking the endpoint is of no interest/value.
Lastly. If the IoT device can handle it... some logging never hurts.
Apologies for repeating some of what CBHacking wrote, i think we were both typing at the same time. The CSRF he mentioned is remediated by the concept of a one-time passcode however... as i mentioned you could use.
– hiburn8
5 hours ago
Thank you for your detailed answer. Would you be able to go into more depth about using a pre-shared key? If it is possible, would you be able to link to a demonstration if such an implementation do I can look into seeing whether it is something I could implement into the ESP8266?
– Rocco
5 hours ago
Based on your hardware limitations, i would imagine the best tradeoff for security and effort (given that you are not protecting the crown jewels but still want to have some assurance) would be to use the current time of the devices to encrypt a string/passphrase. The 'server' would perform this operation once at timed intervals (say per minute) and therefore the client would be able to generate a valid token within this timeframe assuming it's system clock is in reasonably good sync with the server.
– hiburn8
5 hours ago
So i think to make that happen all you really need to do is A) make sure that the clocks/times are in sync for the client and server. B) figure out which forms of encryption are possible on your IoT device. Given that you are only performing encrypt actions every minute and decrypt actions on every request, this shouldnt be a huge performance requirement at all.
– hiburn8
5 hours ago
add a comment |
Unless you want to read around the subject areas involved, this is a simple question with a simple answer. YES, an attacker would need to be connected to your network (given that it is an encrypted network) in order to see the contents of packets and therefor the /openGarage API.
If thats all you care about, we're done. But I will go on to say that even in a non secured (http) environment, it might still be possible to get some level of assurance that no-one is successfully hitting up your API. The way i would do this is have a pre-shared key between the IOT device and server, which are used to generate continuously changing tokens for use to validate each-other. Essentially the same model as a one-time passcode. This seems like something even very basic IoT devices which might struggle to process HTTPS data should be able to achieve. The ideal scenario would be that the 'server' is aware of the last used token, to prevent an attacker from abusing the race-condition to re-use a token.
Pretty much any other attempt to add security would have to rely on obscurity. As a really awful example, you could change '/openGarage' to '/questions' and on that network use a DNS server such that requests appear to be going to 'stackexchange.com/questions'. Depending on what the attacker sees, they might be fooled into thinking the endpoint is of no interest/value.
Lastly. If the IoT device can handle it... some logging never hurts.
Unless you want to read around the subject areas involved, this is a simple question with a simple answer. YES, an attacker would need to be connected to your network (given that it is an encrypted network) in order to see the contents of packets and therefor the /openGarage API.
If thats all you care about, we're done. But I will go on to say that even in a non secured (http) environment, it might still be possible to get some level of assurance that no-one is successfully hitting up your API. The way i would do this is have a pre-shared key between the IOT device and server, which are used to generate continuously changing tokens for use to validate each-other. Essentially the same model as a one-time passcode. This seems like something even very basic IoT devices which might struggle to process HTTPS data should be able to achieve. The ideal scenario would be that the 'server' is aware of the last used token, to prevent an attacker from abusing the race-condition to re-use a token.
Pretty much any other attempt to add security would have to rely on obscurity. As a really awful example, you could change '/openGarage' to '/questions' and on that network use a DNS server such that requests appear to be going to 'stackexchange.com/questions'. Depending on what the attacker sees, they might be fooled into thinking the endpoint is of no interest/value.
Lastly. If the IoT device can handle it... some logging never hurts.
answered 5 hours ago
hiburn8hiburn8
37919
37919
Apologies for repeating some of what CBHacking wrote, i think we were both typing at the same time. The CSRF he mentioned is remediated by the concept of a one-time passcode however... as i mentioned you could use.
– hiburn8
5 hours ago
Thank you for your detailed answer. Would you be able to go into more depth about using a pre-shared key? If it is possible, would you be able to link to a demonstration if such an implementation do I can look into seeing whether it is something I could implement into the ESP8266?
– Rocco
5 hours ago
Based on your hardware limitations, i would imagine the best tradeoff for security and effort (given that you are not protecting the crown jewels but still want to have some assurance) would be to use the current time of the devices to encrypt a string/passphrase. The 'server' would perform this operation once at timed intervals (say per minute) and therefore the client would be able to generate a valid token within this timeframe assuming it's system clock is in reasonably good sync with the server.
– hiburn8
5 hours ago
So i think to make that happen all you really need to do is A) make sure that the clocks/times are in sync for the client and server. B) figure out which forms of encryption are possible on your IoT device. Given that you are only performing encrypt actions every minute and decrypt actions on every request, this shouldnt be a huge performance requirement at all.
– hiburn8
5 hours ago
add a comment |
Apologies for repeating some of what CBHacking wrote, i think we were both typing at the same time. The CSRF he mentioned is remediated by the concept of a one-time passcode however... as i mentioned you could use.
– hiburn8
5 hours ago
Thank you for your detailed answer. Would you be able to go into more depth about using a pre-shared key? If it is possible, would you be able to link to a demonstration if such an implementation do I can look into seeing whether it is something I could implement into the ESP8266?
– Rocco
5 hours ago
Based on your hardware limitations, i would imagine the best tradeoff for security and effort (given that you are not protecting the crown jewels but still want to have some assurance) would be to use the current time of the devices to encrypt a string/passphrase. The 'server' would perform this operation once at timed intervals (say per minute) and therefore the client would be able to generate a valid token within this timeframe assuming it's system clock is in reasonably good sync with the server.
– hiburn8
5 hours ago
So i think to make that happen all you really need to do is A) make sure that the clocks/times are in sync for the client and server. B) figure out which forms of encryption are possible on your IoT device. Given that you are only performing encrypt actions every minute and decrypt actions on every request, this shouldnt be a huge performance requirement at all.
– hiburn8
5 hours ago
Apologies for repeating some of what CBHacking wrote, i think we were both typing at the same time. The CSRF he mentioned is remediated by the concept of a one-time passcode however... as i mentioned you could use.
– hiburn8
5 hours ago
Apologies for repeating some of what CBHacking wrote, i think we were both typing at the same time. The CSRF he mentioned is remediated by the concept of a one-time passcode however... as i mentioned you could use.
– hiburn8
5 hours ago
Thank you for your detailed answer. Would you be able to go into more depth about using a pre-shared key? If it is possible, would you be able to link to a demonstration if such an implementation do I can look into seeing whether it is something I could implement into the ESP8266?
– Rocco
5 hours ago
Thank you for your detailed answer. Would you be able to go into more depth about using a pre-shared key? If it is possible, would you be able to link to a demonstration if such an implementation do I can look into seeing whether it is something I could implement into the ESP8266?
– Rocco
5 hours ago
Based on your hardware limitations, i would imagine the best tradeoff for security and effort (given that you are not protecting the crown jewels but still want to have some assurance) would be to use the current time of the devices to encrypt a string/passphrase. The 'server' would perform this operation once at timed intervals (say per minute) and therefore the client would be able to generate a valid token within this timeframe assuming it's system clock is in reasonably good sync with the server.
– hiburn8
5 hours ago
Based on your hardware limitations, i would imagine the best tradeoff for security and effort (given that you are not protecting the crown jewels but still want to have some assurance) would be to use the current time of the devices to encrypt a string/passphrase. The 'server' would perform this operation once at timed intervals (say per minute) and therefore the client would be able to generate a valid token within this timeframe assuming it's system clock is in reasonably good sync with the server.
– hiburn8
5 hours ago
So i think to make that happen all you really need to do is A) make sure that the clocks/times are in sync for the client and server. B) figure out which forms of encryption are possible on your IoT device. Given that you are only performing encrypt actions every minute and decrypt actions on every request, this shouldnt be a huge performance requirement at all.
– hiburn8
5 hours ago
So i think to make that happen all you really need to do is A) make sure that the clocks/times are in sync for the client and server. B) figure out which forms of encryption are possible on your IoT device. Given that you are only performing encrypt actions every minute and decrypt actions on every request, this shouldnt be a huge performance requirement at all.
– hiburn8
5 hours ago
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f205466%2fdoes-someone-need-to-be-connected-to-my-network-to-sniff-http-requests%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown