Amir Herzberg wrote:

Lance James wrote:

Amir Herzberg wrote:

Lance James wrote:

This site is set so that there is a frame of inside my site. The imaginative part is that you may have to reverse the rolls to understand the impact of this ( with 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.



Best Regards,
Lance James
Secure Science Corporation
Author of 'Phishing Exposed'
Find out how malware is affecting your company: Get a DIA account today! - it's free!

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to