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

How do I hide Chekhov's Gun?

Welcoming 2019 Pi day: How to draw the letter π?

Is it true that good novels will automatically sell themselves on Amazon (and so on) and there is no need for one to waste time promoting?

How do anti-virus programs start at Windows boot?

Existence of subset with given Hausdorff dimension

Employee lack of ownership

What's the meaning of “spike” in the context of “adrenaline spike”?

Are all passive ability checks floors for active ability checks?

Can a druid choose the size of its wild shape beast?

Min function accepting varying number of arguments in C++17

Why does Bach not break the rules here?

how to write formula in word in latex

A link redirect to http instead of https: how critical is it?

Time travel from stationary position?

Why do passenger jet manufacturers design their planes with stall prevention systems?

Co-worker team leader wants to inject his friend's awful software into our development. What should I say to our common boss?

Does someone need to be connected to my network to sniff HTTP requests?

Do I need to be arrogant to get ahead?

PTIJ: Who should I vote for? (21st Knesset Edition)

Interplanetary conflict, some disease destroys the ability to understand or appreciate music

Should we release the security issues we found in our product as CVE or we can just update those on weekly release notes?

Happy pi day, everyone!

Why is the President allowed to veto a cancellation of emergency powers?

Are there other languages, besides English, where the indefinite (or definite) article varies based on sound?



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 3 hours ago









      RoccoRocco

      385




      385




















          2 Answers
          2






          active

          oldest

          votes


















          3














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









          3














          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
            3 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
            2 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
            2 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
            2 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
            2 hours ago















          3














          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
            3 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
            2 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
            2 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
            2 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
            2 hours ago













          3












          3








          3







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

          Möglingen Índice Localización Historia Demografía Referencias Enlaces externos Menú de navegación48°53′18″N 9°07′45″E / 48.888333333333, 9.129166666666748°53′18″N 9°07′45″E / 48.888333333333, 9.1291666666667Sitio web oficial Mapa de Möglingen«Gemeinden in Deutschland nach Fläche, Bevölkerung und Postleitzahl am 30.09.2016»Möglingen

          Virtualbox - Configuration error: Querying “UUID” failed (VERR_CFGM_VALUE_NOT_FOUND)“VERR_SUPLIB_WORLD_WRITABLE” error when trying to installing OS in virtualboxVirtual Box Kernel errorFailed to open a seesion for the virtual machineFailed to open a session for the virtual machineUbuntu 14.04 LTS Virtualbox errorcan't use VM VirtualBoxusing virtualboxI can't run Linux-64 Bit on VirtualBoxUnable to insert the virtual optical disk (VBoxguestaddition) in virtual machine for ubuntu server in win 10VirtuaBox in Ubuntu 18.04 Issues with Win10.ISO Installation

          Torre de la Isleta Índice Véase también Referencias Bibliografía Enlaces externos Menú de navegación38°25′58″N 0°23′02″O / 38.43277778, -0.3838888938°25′58″N 0°23′02″O / 38.43277778, -0.38388889Torre de la Illeta de l’Horta o Torre Saleta. Base de datos de bienes inmuebles. Patrimonio Cultural. Secretaría de Estado de CulturaFicha BIC Torre de la Illeta de l’Horta. Dirección General de Patrimonio Cultural. Generalitat ValencianaLugares de interés. Ayuntamiento del CampelloTorre de la Isleta en CastillosNet.org