0

Usually I differentiate phished page and normal web pages by seeing https before the address of the web page, as the lock symbol will help us to identify.

Are there any other methods to differentiate phished login pages and normal web page?

Polynomial
  • 132,208
  • 43
  • 298
  • 379
BlueBerry - Vignesh4303
  • 5,107
  • 13
  • 34
  • 63
  • 3
    check the action attribute of form TAG in source code – open source guy Aug 22 '12 at 14:39
  • 1
    @dippu the `action` attribute could be legitimate, but the phising website could have a script that sends all the information you wrote to other place... – eversor Aug 22 '12 at 15:35
  • @eversor The `action` attribute may also have been modified by JavaScript, or the form's post event might be (as you said) hooked. – Polynomial Aug 22 '12 at 17:45
  • @Polynomial do you mean something like, when the user clicks the submit button, the script changes the `action` attribute? – eversor Aug 22 '12 at 18:31
  • 1
    @eversor Doesn't even need to be that. It could do it during `onload`. The view source functionality in most browsers shows the markup that was *delivered*, not the markup that is currently in the document. – Polynomial Aug 22 '12 at 19:14

4 Answers4

4

Doing a test login with fake credentials I think is the best way. You could examine the Net using debuggers as FireBug (mozilla plugin) or Chrome debugger to look where the information is being sent, or if you are being redirected to other web etc.

Also you should pay attention to the domain, thisisalongdomain.com and thisisalongdoman.com might seem equal, but if you look carefully you will notice the difference.

Other way is searching it on google (or other search engine). Usually the real website would appear before, (but this is not 100% secure). Or you might even find that that phising web have been reported.

Usually checking the https is a good option, but if a trusted CA gets compromised, bear in mind that you could end up in a https web that is not the real web.

Edit: For users with not enough IT knowledge, I recommend not to trust links on unsafe environments, like an email from an unknown sender, a chatroom or a forum since most phising attacks rely on those mechanisms to succeed. I will be surprised if a phising website gets to the firsts possitions of a search engine...

Apart from paying attention to visible (at first sigh) things as the url, as I said before, or the httpS as vignesh said, there is little more they could do by theirown if they fall in a phising website.

I think they should totally use antivirus, nowadays they tend to warn you if a website is a phising website (at least Norton and McAfee do), this could safe lives, but of course, with new phising websites, I guess they will not warn you.

eversor
  • 914
  • 4
  • 8
  • 22
  • i agree with all of your point sir,this answer would be more suitable for those whom aware of **computer usage**,think about an end user whom is new to computer,how can he/she easily identify it,i usually recommend **https** but as you said it too can be faked so any other sir? – BlueBerry - Vignesh4303 Aug 22 '12 at 15:10
  • 1
    @vignesh I think that the advice, checking the https, is a good advice, websites with *fake* https are exceptions, but we could not ignore that possibility. But appart from that, I would concentrate my efforts in making them aware of the risks of internet and, since most of phising cases are perpetrated via email, let them know that they should never open, or click links of, emails from unknown sources, banks (they never send emails), and in general any email that they have not requested. In a nutsell, do not trust your emails. And with chatrooms etc. it is exactly the same. – eversor Aug 22 '12 at 15:30
3

Check the URL: The URL should not contain anything that looks like code or a URL for a weird website (i.e. paypal.com/login?username=http://hack.ru or paypal.com/login?username=<script>hack();</script>). Preventing XSS should be the biggest one.

Next Also... warn them that they should check for the code after the page has loaded to avoid being confused between a shortened bit.ly link and the actual url.

Expectations: Your post on @eversor's post indicates you want a user to validate the page is not phished. A user is stupid. If they don't know things about how their computer works and how the internet works how can they be expected to understand what pages may be compromised...

Warn them to look for things that look out of place, make sure there is no code in the address bar, expect your users who don't know how phishing works to fall victim to it, and respond accordingly.

And use good browsers. Chrome and IE have surprised me at how well they stop most basic XSS.

One more thing. Here is a good link about phishing I just saw. "Phishing" red flags and countermeasures

Community
  • 1
2

Usually I differentiate phished page and normal web pages by seeing https before the address of the web page

It's not really clear what you're asking here. Do you mean how would you as a user differentiate between a phishing site for a service you use and a legitimate site? Checking for SSL only differentiates if the legitimate site uses https. While the hosname is a also a good clue, it's not the full story - leaving aside SSL, there's lot's ways it can be faked. Checking for both SSL and a the host name will catch most problems - it's still possible to compromise the integrity of this approach, e.g. if the client machine has a compromised root CA database / DNS resolution.

If you run a webserver and want to provide additional protection for your users, then, in addition to SSL, use HSTS and a content security policy.

symcbean
  • 18,278
  • 39
  • 73
1
  • As an administrator of your web site, one way to make sure that your website contains all the valid files, and URL redirections is to create MD5 checksums of all the files and save in external/detachable drive so that only you/trusted group has access to the file. (e.g. MD5SUMMER: http://sourceforge.net/projects/md5summer/)
  • Secondly, you can make a script notifying you to violation of the mD5 checksums. That way you need not sit down and manually compute MD5 checksums and verify all of then.
C2940680
  • 111
  • 1
  • 1
    Fishing usually involves modifying the DOM of the page after the files have been read on the server's side. Verifying the source files won't help against, say, URL-based XSS. – B-Con Aug 22 '12 at 18:39