IPhone Devs, don't put your private keys for push notification in your webroot

[ssclafani]

http://www.google.com/search?q=inurl:apns+filetype:pem

[BenSS]

I'm glad that doing it this way has never, ever occurred to me. Would you publish your private ssh key?

[uxp → BenSS]

That is a good question: https://encrypted.google.com/search?sourceid=chrome&ie=U...

[btipling → uxp]

I just made encrypted.google.com my default search.

[JonnieCache → btipling]

Fun fact: SSL sites don't send referer headers, so sites can't sniff your search keywords.

[Johngibb → btipling]

Unfortunate bug: if you hit encrypted.google.com on an iPhone, you're redirected to the unencrypted mobile version of the site... Not good!

[uxp → Johngibb]

https://www.google.com/m works, it looks like.

[ssclafani]

Hat tip to Billy Rios https://twitter.com/#!/XSSniper/status/46292790933590017

[fuzzmeister]

Fun fact: every single URL on the first page of results also has Apache directory listing enabled.

[A1kmm → fuzzmeister]

I expect that is why they are indexed - they aren't exactly going to link to their private key from another page.

[fuzzmeister → A1kmm]

Ah, good point.

[oemera]

Wait. Does that mean I could send messages to all users using the app which is paired to this key? Hopefully no-one finds this out :/

[BenSS → oemera]

If you get the device tokens too, possibly. Unfortunately it looks like some of these are ALSO exposed. Argh.

http://developer.apple.com/library/ios/documentation/Network...

[bkaid → oemera]

No - each user is assigned a token that you would also need to use in combination with the private key.

[jonhohle → bkaid]

You could get all of the feedback pending for that key, as well, which would expose tokens, and potentially disrupt service.

[jonny_eh]

What does having these keys allow?

[mman → jonny_eh]

A UIApplication method (registerForRemoteNotificationTypes:) negotiates with apples servers using device information to obtain a 32-byte push token unique to a given device/app pair. It is likely based on the device's global id (UDID) and the application's appid and certificates. Someone should figure out the exact network handshake.

Any app developer is capable of collecting UDIDs using their released apps (the UDID is constant and visible across all apps). Note, having the UDID does not necessarily mean you can obtain the push token. But you may be able to derive the push token from it and from information contained in the app.

Assuming you could figure out someone's push token, you could to cause a push to show up in the name of the app whose certificate/key you've obtained!

[oasisbob → mman]

> 32-byte push token unique to a given device/app pair. It is likely based on the device's global id (UDID) and the application's appid and certificates.

This isn't quite correct, the device token is not unique per app, it's unique per device. (Technically, a device will have two tokens, one for the APNS sandbox, and the second for production.)

The device token can't be derived by mere mortals, it is a cryptographic identifier returned from APNS to the device.

[BenSS → oasisbob]

Unfortunately, by a bit of digging I was able to reveal some actual push tokens. I could now send messages to an app that is not mine!