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 [EMAIL PROTECTED]