Фишинг с URL Obfuscation продължава в Safari 4

Е, трудно е да се повярва, но новата версия на Apple’s браузър “Сафари 4” все още продължава да бъде уязвим към техниките на обфуксация на URL. Всички други доставчици на браузъри, независимо дали е Internet Explorer, Firefox, Opera или Chrome, са отстранили този проблем отдавна. Всички обаче бяха решили този проблем, използвайки съвсем различни решения, което повдига въпроса, който не би трябвало’t те следват общ стандарт ??


За тези от вас, които го правят’не знам какво е обсебване на URL адрес, това е вековна техника, която фишъри използват за подправяне на законни уебсайтове като популярни банки и др. Фишерът ще изпраща спам имейли с претенции, че идват от вашата банка и ако паднете за измамата, може да се окажете да се откажете от пълномощията си Сред популярните техники, тази, която смятам, е най-важната, тъй като се опитва да използва вградената автентификация на връзката, която се извършва с използване на URL формат HTTP: // потребителско име: [email protected]. Нападателят може да използва прекалено дълги URL адреси да скриете напълно подозрителната част в адресната си лента, която е “@ evilwebsite.com” или нещо подобно “@evilwebsiteip (xx.xx.xx.xx)” с различни методи за кодиране на номера.

За моето тестване направих следното: {Забележка: IP променен от последната публикация, изображенията имат стар IP}

1. Поставих този URL адрес в браузъра’s адресна лента

2. Наведох се върху тази хипервръзка и забелязах моя STATUS BAR [Ширина на прозореца трябва да бъде <= 1024]

Ето резултатите:

Safari 4.0 (530.17): Сафари е уязвим към този подвиг. Не предприема никакви стъпки за смекчаване на този проблем. В адресната лента прекалено дългият URL адрес продължава да се показва такъв, какъвто е след отварянето на уеб страницата и следователно нормалният потребител е много вероятно да падне плячка за тази фишинг атака (вижте изображението по-долу). Също така лентата на състоянието е деактивирана по подразбиране. Тъй като повечето потребители не’t промени настройките по подразбиране, потребителят отново е по-вероятно да стане плячка, когато щракне върху хипервръзка някъде в мрежата. Ако сте изрично активирали лентата на състоянието, тогава можете да идентифицирате злия сайт. Причината е, че Safari прави отрязване на дългия URL адрес чрез пускане “..” в средата, така че ще видите подозрителната част в края.

6__500x400_urlobfuscation16__500x400_urlobfuscation1

Опера 9.64: Opera има някои стратегии за смекчаване, за да се предпази от този подвиг. Ще се покаже изскачащ прозорец, предупреждаващ потребителя, че потребителско име е въведено като част от URL адреса. Потребителското име в съобщение за грешка може да бъде малко объркващо за потребителя и в идеалния случай то вместо това трябва да постави името / ip на злия сайт, който е по-добър показател (този, който Firefox използва). Друга тъжна част е “ДА” бутонът е опцията по подразбиране. Така че, ако потребителят не разбира съобщението или случайно натиска “ENTER” (което повечето хора правят, когато видят изскачащи прозорци), те могат да станат жертва на тази фишинг атака. Относно частта на лентата на състоянието, когато задържите курсора на мишката върху прекалено дълга хипервръзка, Opera я съкращава в края (което е лошо), така че спечелихте’не виждате злата информация за сайта в края на URL адреса.

9__500x400_urlobfuscation49__500x400_urlobfuscation4

Chrome 2.0.172.31: Замразеният URL адрес работи в Google Chrome, но Google предприе важни мерки за смекчаване, за да предотврати цялостно фишинг. Първото нещо, което не показват “потребителско име: парола @” част от URL адреса, когато задържите курсора на мишката върху връзка. Второто нещо, което правят, е да съблекат “потребителско име: парола @” част от URL адреса, когато посещава този URL адрес, така че потребителят ясно вижда злото име на сайта или ip. Това определено прави потребителя подозрителен и следователно спечелен’не падне за подвига. Последното нещо, което правят е да преобразуват десетични адреси в пунктирана четвъртична нотация.

7__500x400_urlobfuscation27__500x400_urlobfuscation2

Internet Explorer 7.0.5730.13: Internet Explorer спря да поддържа формат за URL адрес за удостоверяване на базата на връзки от IE7 нататък. Освен това, ако поставите тези дълги URL адреси в хипервръзки, те спечелиха’не работи, дори ако потребителят кликне върху тях. Така че, ДА, не сте уязвими от този подвиг в IE. Имам обаче притеснение от повдигнатото съобщение за грешка “Windows не може да намери …” когато потребител се опита да получи достъп до такива URL адреси. Наистина чувствам, че Microsoft трябва да подобри съдържанието на това съобщение, тъй като в противен случай нормален потребител може да мисли, че IE не е в състояние да отвори такива URL адреси и може да опита да използва други браузъри като Safari, където те стават плячка за неговата фишинг атака.

8__500x400_urlobfuscation38__500x400_urlobfuscation3

Firefox 3.5 Beta 4: Последно, но не най-малко Firefox. Много харесвам Firefox, който интелигентно решава съдържанието на съобщенията за грешки. Ако вашият сайт не поддържа HTTP Basic Authentication, не може да има потребителска кутия на потребител, предоставяща автентични идентификационни данни. И така, тя повдига важно съобщение, че се подлъгвате. Включва и сайта на злото’s име или ip и потвърждава с вас, ако искате да отидете там. Също, “НЕ” бутонът е избор по подразбиране. Има почти 0% вероятност човек да стане плячка за тази фишинг атака тук. По отношение на частта на лентата на състоянието, когато задържите курсора на прекалено дълга хипервръзка, Firefox го съкращава в края (точно като Opera, което е лошо), така че вие ​​спечелихте’не виждате злата информация за сайта в края на URL адреса.

10__500x400_urlobfuscation510__500x400_urlobfuscation5

Чувствам, че общите техники за смекчаване трябва да се прилагат еднакво във всички браузъри. Ако комбинираме техниките, използвани от Firefox и Chrome, можем да постигнем най-доброто от двата свята, което е да продължим да поддържаме автентификация на базата на връзки и смекчаване на уязвимостите в сигурността, произтичащи от объркване на URL адреси, с прекалено дълги URL адреси.

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me