IDN Spoofing Issue
-
- Guest
-
- Guest
-
- Guest
This may be naive, but since the problem is that a human cannot see the difference, couldn't we try to simulate this behaviour on the computer side ? For example, we could render the url in a normalized font, and then try a pattern matching with ascii char. If there is a match and that the found domain name exists, warn the user that he may be the victim of a spoofing attack.
This would be like this:
(fake encoded paypal.com) -> render -> (pixels) -> pattern matching -> (paypal.com in text form) -> (paypal.com exists - possible spoofing) -> warn.
I'm not sure how easy it is to implement, however.
This would be like this:
(fake encoded paypal.com) -> render -> (pixels) -> pattern matching -> (paypal.com in text form) -> (paypal.com exists - possible spoofing) -> warn.
I'm not sure how easy it is to implement, however.
-
- Posts: 1632
- Joined: August 27th, 2003, 1:42 pm
- Location: Michigan
- Contact:
-
- Guest
thanks. works a treat now. had to remove:
@mozilla.org/network/idn-service;1,{62b778a6-bce3-456b-8c31-2865fbb68c91}
{xxx},@mozilla.org/network/idn-service;1,application/x-mozilla-static,nsIDNService,necko_core_and_primary_protocols
{xxx},@mozilla.org/network/idn-service;1,application/x-mozilla-static,nsIDNService,necko_core_and_primary_protocols
But two thoughts:
1. i'm assuming it fails because mozilla is silently translates codes like #xxxx into their proper values? Why not just show in the url the value contained in the link without translating it but still use the converted string internally? that way the same phishing problem will be made visible?
2. who's daft idea was it to allow non-ascii codes for domain names when it breaks the ability to make a url universally readable and accessible?
Neil.
@mozilla.org/network/idn-service;1,{62b778a6-bce3-456b-8c31-2865fbb68c91}
{xxx},@mozilla.org/network/idn-service;1,application/x-mozilla-static,nsIDNService,necko_core_and_primary_protocols
{xxx},@mozilla.org/network/idn-service;1,application/x-mozilla-static,nsIDNService,necko_core_and_primary_protocols
But two thoughts:
1. i'm assuming it fails because mozilla is silently translates codes like #xxxx into their proper values? Why not just show in the url the value contained in the link without translating it but still use the converted string internally? that way the same phishing problem will be made visible?
2. who's daft idea was it to allow non-ascii codes for domain names when it breaks the ability to make a url universally readable and accessible?
Neil.
-
- Guest
Suggestion...
Hi, I am just a Mozilla user from a while back, switched to Firefox when it came out (before all the name changes).
Anyway, I got a suggestion on working with this "flaw" in the IDN.
The address bar should use color coding to show non-local characters. (Like it does with secure sites).
How it works:
-The browser will notice the character being used isn't in the Local's character set.
-And upon presentation, it renders those specific characters differently. It can be colored red, bolded, or backgrounded gray....
Local can be set by the user whether it be Japan, India, or Brazil.
We would also need "friendly Locals" so that users won't see lots of colored characters. Like Japanese would have a Japanese Local and the US as a friendly Local so that english and japanese site addresses show up as normal text.
From a user's point of view, the sites' addresses would look different. This won't get rid of the problem, but I believe it will make it much smaller.
I am pretty sure someone already has this idea or a better one, but I didn't think it would hurt to post just incase noone did.
Anyway, I got a suggestion on working with this "flaw" in the IDN.
The address bar should use color coding to show non-local characters. (Like it does with secure sites).
How it works:
-The browser will notice the character being used isn't in the Local's character set.
-And upon presentation, it renders those specific characters differently. It can be colored red, bolded, or backgrounded gray....
Local can be set by the user whether it be Japan, India, or Brazil.
We would also need "friendly Locals" so that users won't see lots of colored characters. Like Japanese would have a Japanese Local and the US as a friendly Local so that english and japanese site addresses show up as normal text.
From a user's point of view, the sites' addresses would look different. This won't get rid of the problem, but I believe it will make it much smaller.
I am pretty sure someone already has this idea or a better one, but I didn't think it would hurt to post just incase noone did.
-
- Guest
A simpler way of fixing this is as follows :-
1. Install the Adblock Firefox extension.
https://update.mozilla.org/extensions/m ... dows&id=10
2. Look at the Adblock 'Preferences' and go to 'Adblock Options'
3. Tick 'Site Blocking'
4. Add the following filter :-
/[^\x20-\xFF]/
This will block any URL that uses characters outside the normal ASCII range.
1. Install the Adblock Firefox extension.
https://update.mozilla.org/extensions/m ... dows&id=10
2. Look at the Adblock 'Preferences' and go to 'Adblock Options'
3. Tick 'Site Blocking'
4. Add the following filter :-
/[^\x20-\xFF]/
This will block any URL that uses characters outside the normal ASCII range.
-
- Posts: 36
- Joined: July 13th, 2004, 12:14 pm
Restart after modifying compreg.dat
I commented out the IDN lines in compreg.dat as suggested here, and then tested at the Secunia site http://secunia.com/multiple_browsers_idn_spoofing_test/
Didn't work.
Closed Mozilla and re-opened. Now it passes the test.
EB
Didn't work.
Closed Mozilla and re-opened. Now it passes the test.
EB
-
- Guest
Works great
KevinMillican wrote:A simpler way of fixing this is as follows :-
1. Install the Adblock Firefox extension.
https://update.mozilla.org/extensions/m ... dows&id=10
2. Look at the Adblock 'Preferences' and go to 'Adblock Options'
3. Tick 'Site Blocking'
4. Add the following filter :-
/[^\x20-\xFF]/
This will block any URL that uses characters outside the normal ASCII range.
-
- Guest
-
- Guest
Deactivate IDN problem
Using wordpad, when I find the file compreg.dat to edit by placing # in front of the line with IDN, the top of the file says "Generated file-do not edit " Moreover, it does not look like the sample suggested for the fix of the problem -- line starts with @Mozilla rather than the sample showing { .......}, @ Mozilla
What do us tech illiterates do?
What do us tech illiterates do?
