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













2















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.










share|improve this question


























    2















    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.










    share|improve this question
























      2












      2








      2








      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.










      share|improve this question














      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 6 hours ago









      RoccoRocco

      385




      385




















          2 Answers
          2






          active

          oldest

          votes


















          4














          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.






          share|improve this answer























          • 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












          • 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


















          2














          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.






          share|improve this answer























          • 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










          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
          );



          );













          draft saved

          draft discarded


















          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









          4














          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.






          share|improve this answer























          • 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












          • 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















          4














          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.






          share|improve this answer























          • 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












          • 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













          4












          4








          4







          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.






          share|improve this answer













          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          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 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












          • 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











          • 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













          2














          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.






          share|improve this answer























          • 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















          2














          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.






          share|improve this answer























          • 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













          2












          2








          2







          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.






          share|improve this answer













          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          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

















          • 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

















          draft saved

          draft discarded
















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          名間水力發電廠 目录 沿革 設施 鄰近設施 註釋 外部連結 导航菜单23°50′10″N 120°42′41″E / 23.83611°N 120.71139°E / 23.83611; 120.7113923°50′10″N 120°42′41″E / 23.83611°N 120.71139°E / 23.83611; 120.71139計畫概要原始内容臺灣第一座BOT 模式開發的水力發電廠-名間水力電廠名間水力發電廠 水利署首件BOT案原始内容《小檔案》名間電廠 首座BOT水力發電廠原始内容名間電廠BOT - 經濟部水利署中區水資源局

          Prove that NP is closed under karp reduction?Space(n) not closed under Karp reductions - what about NTime(n)?Class P is closed under rotation?Prove or disprove that $NL$ is closed under polynomial many-one reductions$mathbfNC_2$ is closed under log-space reductionOn Karp reductionwhen can I know if a class (complexity) is closed under reduction (cook/karp)Check if class $PSPACE$ is closed under polyonomially space reductionIs NPSPACE also closed under polynomial-time reduction and under log-space reduction?Prove PSPACE is closed under complement?Prove PSPACE is closed under union?

          Is my guitar’s action too high? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)Strings too stiff on a recently purchased acoustic guitar | Cort AD880CEIs the action of my guitar really high?Μy little finger is too weak to play guitarWith guitar, how long should I give my fingers to strengthen / callous?When playing a fret the guitar sounds mutedPlaying (Barre) chords up the guitar neckI think my guitar strings are wound too tight and I can't play barre chordsF barre chord on an SG guitarHow to find to the right strings of a barre chord by feel?High action on higher fret on my steel acoustic guitar