I use this exact method for fraud detection. 99% of the time, carders " " will simply load up a proxy in Firefox/Chrome (usually a socks5) and fire away. They typically don't tunnel their whole connection through the proxy, just their browser.
If their request IP doesn't match up with this IP, there's a very high chance that the order will is fraudulent.
Interesting. We check to see if Javascript timezone matches GeoIP and/or billing/shipping address. Also Canvas fingerprinting works well. Lastly measuring latency is another good one since you can't cheat the speed light.
As much as I'm happy that you're able to detect fraudulent transactions, I am really disappointed that there's not a Content Security Policy rule to prevent WebRTC :-(
Another useful heuristic is to check if the client is coming in from a public Tor exit. YMMV depending on the nature of goods being sold, but in our case not a single legit purchase came in this way and nearly all fraudulent purchases were through Tor.
Not that i'm a expert. But i think only amateurs would be so foolish. Nearly all open proxys out there forward the clients real IP in the HTTP X-FORWARDED-FOR header.
This can be disabled in firefox's about:config page by setting media.peerconnection.enabled to false.
The problem with disabling all these features on a case by case basis is that you contribute to a richer fingerprint this way. Browsers will become increasingly more vulnerable to fingerprinting and there doesn't seem to be a way to stop it without going back to the dark ages of the web.
There really needs to be a writeup of all the Firefox defaults to change to make your browser actually secure. That's one I didn't know about. I think that your local IP is actually going to be very unique for some people, more so than just having this "feature" disabled.
Privacy at the browser level is hopeless! The answer is to compartmentalize. This VM and its convoluted Internet connectivity are pure Mirimir. I care not that the browser has been fingerprinted, that my IP has been logged, that evercookies have been placed, etc, etc, etc.
That is an important piece of information, but viewers be advised: that page has a non-work-safe background and is NOT exactly a copy of the GitHub demo page (and has other obfuscated JavaScript running on it).
"Additionally, these STUN requests are made outside of the normal XMLHttpRequest procedure, so they are not visible in the developer console or able to be blocked by plugins such as AdBlockPlus or Ghostery. This makes these types of requests available for online tracking [...]"
Its particularly interesting in that it gets ALL my local ip addresses. This seems quite dangerous. Could they just start probing around my local network or does cross domain stuff kick in?
I don't see how. WebRTC may leak your local IP, but that doesn't mean someone outside your local network can interact with it (without compromising a machine on said network).
Holy cow. Browser devs seem to become crazier by the minute. Combine this with the lack of a same-origin policy in the JavaScript websocket API and you can really poke around in the local network.
Well, for websockets it's up to the server to check if the connection should be accepted or not. Same as in CORS whnere the server sais who is allowed to access the resources, not the browser.
There's no SOP in the JS websocket API because websockets are a newly-designed protocol specifically for the use case of being called from JS. If you have websocket servers on your local network (... although, why?) they know they should be checking origin.
The demo reported 192.168.56.1 as a local IP. Now they know I have VirtualBox installed. I wonder what other IPs can leak information about common apps and network configs.
This is pretty good timing. I got an email from Braintreepayments this week that I needed to implement some code changes for fraud detection and paypal before march. Upon integrating this code I noticed some odd data being sent back:
https://www.braintreepayments.com/docs/ruby/general/fraud_to...
It turns out that this script must employ this techinque. After inspecting the requests in chrome Dev tools it appears all my private ips were being collected and sent over the wire back to Braintree (or whatever company is hosting their fraud detection).
Fails in Firefox nightly with the following errors:
This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.[Learn More] webrtc-ips
TypeError: Not enough arguments to mozRTCPeerConnection.setLocalDescription.
Here's me hoping they're addressing these concerns already.
I've been using it for almost a year on sharedrop.io (p2p file transfer app) to distinguish peers in the same local network. The code I'm using for finding local IP comes from http://net.ipcalf.com. The app even allows you to select your local IP in case you got more than one, e.g. because of VPN.
No. Your public IP has always been available to a Javascript developer who knows enough to write a one-line PHP script that prints $_SERVER['REMOTE_ADDR'] (as an example). This just makes it available via another protocol.
The new bit is that you can now get local IPs. But that doesn't help someone trying to figure out if you're using a VPN.
Doesn't work for me, thankfully. The funny thing is, I have enough different privacy and security addons that I don't even know which one is protecting me here (best bet is possibly NoScript, even though I allowed scripts on that page).
[+] [-] joshmn|11 years ago|reply
If their request IP doesn't match up with this IP, there's a very high chance that the order will is fraudulent.
[+] [-] adrr|11 years ago|reply
[+] [-] Torgo|11 years ago|reply
[+] [-] vld|11 years ago|reply
[+] [-] huhtenberg|11 years ago|reply
Another useful heuristic is to check if the client is coming in from a public Tor exit. YMMV depending on the nature of goods being sold, but in our case not a single legit purchase came in this way and nearly all fraudulent purchases were through Tor.
[+] [-] sauere|11 years ago|reply
[+] [-] throwaway125|11 years ago|reply
The problem with disabling all these features on a case by case basis is that you contribute to a richer fingerprint this way. Browsers will become increasingly more vulnerable to fingerprinting and there doesn't seem to be a way to stop it without going back to the dark ages of the web.
[+] [-] 13|11 years ago|reply
[+] [-] ChrisAntaki|11 years ago|reply
I wish Chrome would provide this setting too.
[+] [-] userbinator|11 years ago|reply
That probably means I share the same fingerprint as everyone else using the same browser with JS disabled.
[+] [-] mirimir|11 years ago|reply
[+] [-] trainbeeps|11 years ago|reply
Edit: owfffjaqvllmh4zi.onion reveals true IP addresses when using Chrome through Privoxy and Tor chain.
[+] [-] jwise0|11 years ago|reply
[+] [-] hbbio|11 years ago|reply
http://jsfiddle.net/alokmenghrajani/0qo4kq7x/
[+] [-] amenghra|11 years ago|reply
[+] [-] zobzu|11 years ago|reply
[+] [-] mtmail|11 years ago|reply
So the extra effort to get around adblockers?
[+] [-] hackcasual|11 years ago|reply
[+] [-] donatj|11 years ago|reply
[+] [-] doktrin|11 years ago|reply
[+] [-] binwiederhier|11 years ago|reply
[+] [-] wereHamster|11 years ago|reply
[+] [-] geofft|11 years ago|reply
[+] [-] mattaustin|11 years ago|reply
[+] [-] The_Fox|11 years ago|reply
[+] [-] droithomme|11 years ago|reply
[+] [-] benmorris|11 years ago|reply
It turns out that this script must employ this techinque. After inspecting the requests in chrome Dev tools it appears all my private ips were being collected and sent over the wire back to Braintree (or whatever company is hosting their fraud detection).
[+] [-] totony|11 years ago|reply
media.peerconnection.enabled is set to true
EDIT: hbbio's jsfiddle works
[+] [-] diafygi|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] snake_plissken|11 years ago|reply
Edit: Apparently it is by design; ICMP ECHOs are blocked by default on AWS instances, on which stun.services.mozilla.com [54.172.47.69] is running. http://aws.amazon.com/articles/1145?_encoding=UTF8&jiveRedir...
[+] [-] desdiv|11 years ago|reply
1. Are you currently using WebRTC in any projects?
2. Are you planning on using WebRTC in the future?
3. Do you think that WebRTC should be enabled by default in browsers?
[+] [-] contingencies|11 years ago|reply
[+] [-] daGrevis|11 years ago|reply
2. Obviously,
3. With explicit permit from user each time it's needed (like it's for webcam);
[+] [-] josteink|11 years ago|reply
[+] [-] szimek|11 years ago|reply
[+] [-] olalonde|11 years ago|reply
[+] [-] The_Fox|11 years ago|reply
The new bit is that you can now get local IPs. But that doesn't help someone trying to figure out if you're using a VPN.
[+] [-] nfriedly|11 years ago|reply
[+] [-] madeofpalk|11 years ago|reply
[+] [-] blueskin_|11 years ago|reply
[+] [-] aikah|11 years ago|reply
[+] [-] ChrisAntaki|11 years ago|reply
[+] [-] slang800|11 years ago|reply