3

I have an AdWords script that regularly transfers sensitive data to my server using a POST HTTP request. For security I have a predefined 32 character randomized string that is verified by my server before it accepts the data. Is this secure?

I don't know too much about the HTTP protocol, but I know that the data is being sent unencrypted. Is it probable/possible for somebody to access the data during the request? From what I've understood, the HTTPS protocol is most useful when on an untrusted network where it's easy for anybody to spy on your packets. In my case, data is being sent from Google's servers to my host's servers (DreamHost in this case). Would it be prudent of me to upgrade to HTTPS, or would this be pointless? Are there any other security pitfalls I should be aware of?

I will accept the first answer that clears up my situation.

Jim G.
  • 8,006
  • 3
  • 35
  • 66
Hubro
  • 676
  • 1
  • 7
  • 13
  • *...Data is being sent from Google's servers to my host's servers...* Can you elaborate a little more? Is Google hosting your web page? Or is this logic running on a cloud-based backend server? The context matters greatly. – Jim G. Mar 11 '13 at 23:51

3 Answers3

3

Your packets including the secure key can be sniffed. If not encrypted by HTTPS or some other protocol your wide open to the wild wild Internet

Mark
  • 249
  • 2
  • 6
2

It would indeed be prudent to upgrade to HTTPS. Once upon a time, SSL certificates needed for HTTPS were expensive, but these days I've seen them for ridiculously low prices like $6 per year.

Whether it is actually probable/possible for somebody to access the data during the request - look, realistically, it probably isn't. You're not making this communication over the free wi-fi in a coffee shop. But I honestly don't think it is worth trying to save a few dollars a year by not using HTTPS.

Surely there is (or could be in the future) some other functionality on your web application that could benefit from HTTPS?

Carson63000
  • 10,510
  • 1
  • 28
  • 50
  • I don't know dreamhost's configuration but it might happen that other customers are in the same network segment and can enable promiscous scanning and therefore read it, who certainly could read it are dreamhost admins, some network exchange admins and google folks - all of those have certainly more interesting data they could look at ;) That aside: Paying those $6/year is not needed, one can use a self signed certificate and then verify the id yourself. – johannes Mar 12 '13 at 00:04
  • The $6 certificates are not those used by e-commerce websites. Generally, you either go with self signed or full-paid certs. – Florian Margaine Mar 12 '13 at 07:36
  • @FlorianMargaine: is there any difference other than how stringent the identity verification is? And if you're only using HTTPS for encryption (not proof of identity), does that matter? – Carson63000 Mar 12 '13 at 09:17
0

No because somebody could easily inspect your JavaScript, capture the randomized key, and spoof the input.

That is, unless your input is encrypted or hashed; and of the two, hashing is definitely the better option.

Also - Another question - Is your randomized key randomized on a per-user or per-session basis? If it's neither, and you're using a global key, then I'd say that you're very vulnerable to spoofing.

EDIT: In light of the fact that this code is running on Google App Engine, you aren't as vulnerable to spoofing (unless a Google engineer could potentially inspect your code). So generally speaking, as others have already stated, eliminate man-in-the-middle attacks with HTTPS.

Jim G.
  • 8,006
  • 3
  • 35
  • 66
  • 1
    I'm guessing you've misunderstood the question - this is an AdWords script run by Google App Engine. It's not viewable by anybody except me. The key is static and predefined and will never be changed (unless I get a reason to). – Hubro Mar 11 '13 at 23:51
  • @CodeMonkey: OK. You listed PHP as one of your question tags, so it wasn't clear to me. – Jim G. Mar 11 '13 at 23:55
  • My server uses PHP. You're probably right that it's not relevant... – Hubro Mar 11 '13 at 23:55
  • @CodeMonkey: I just updated the tags. Hope I was helpful. – Jim G. Mar 11 '13 at 23:56