[Anti-fraud] Re: Feature or Flaw?

[Lance James]

Amir Herzberg wrote:

> Lance James wrote:
>
>> Amir Herzberg wrote:
>>
>>> Lance James wrote:
>>> ...
>>>  > https://slam.securescience.com/threats/mixed.html
>>>
>>>>
>>>> This site is set so that there is a frame of 
>>>> https://www.bankone.com inside my 
>>>> https://slam.securescience.com/threats/mixed.html site. The 
>>>> imaginative part is that you may have to reverse the rolls to 
>>>> understand the impact of this (https://www.bankone.com with 
>>>> https://slam.securescience.com frame -> done via cross-user attacks
>>>
>>>
>>> Ok, I can do the `mental exercise` and understand the attack. But 
>>> I'm not sure what is new here. Yes, if a web-site allows such XSS, then 
>>
>>
>> It's not the "new" issue - it's the concern that frames with other 
>> SSL protect information is not being indicated to the user, thus you 
>> can encrypt data with another valid cert within a frame(s) and the 
>> user will only know of the main cert from the domain that is 
>> indicated by the address bar.
>
> Well, but I don't see that this has much to do with SSL, really. The 
> problem is that the attacker is able to cause the server to send a 
> page controlled (partially or fully) by the attacker. This should not 
> happen. SSL is only supposed to ensure that the client got the page as 
> the server sent it - and this does happen. Of course, this cannot 
> protect against an infinite list of possible errors and 
> vulnerabilities of the server:
> -- XSS attacks
> -- Defacement
> -- an employee intentionally putting a script to do <something>

I agree that so far this issue only lies within an XSS or already 
compromisable setup against SSL - so again, the site is considered 
compromised - but, the fact that embedded objects can be called into 
play that are considered "protected" within another frame can not be 
identified by the user, in my opinion, may cause unforeseeable risks.

> ...
> I think that your complaint/observation is that browsers normally warn 
> when displaying a page which is partially protected and partially not, 
> but may not complain when displaying a page protected by cert X, but 
> including frame protected by cert Y. Well, this can be fixed, but I'm 
> not sure this is really important. The problem is really the fact that 
> the page was modified in the first place. Instead of including a 
> protected (or unprotected) frame with the rogue code, the attack could 
> have sent the rogue code directly from the compromised site.

This is technically true, the attacker can easily divise it's own forms 
and make it work rather easily (of course in the real world, the link 
would be a bit excessive when used in a phishing attack). I bring this 
up, for the same reason the "Secunia Javascript origin" vulnerability 
was brought up - is that really a flaw??? I'm not attempting to be 
alarmist, I'm trying to drive a point home.

Thoughts?

-- 

Best Regards,
Lance James
Secure Science Corporation
www.securescience.net
Author of 'Phishing Exposed'
http://www.securescience.net/amazon/
Find out how malware is affecting your company: Get a DIA account today!
https://slam.securescience.com/signup.cgi - it's free!


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com