V
VK
<quote cite="http://en.wikipedia.org/wiki/JavaScript#Cross-
site_vulnerabilities">
A common JavaScript-related security problem is cross-site scripting,
or XSS, a violation of the same origin policy. XSS vulnerabilities
occur when an attacker is able to cause a trusted Web site, such as an
online banking website, to include a malicious script in the webpage
presented to a victim. In that example, the script can then access the
banking application with the privileges of the victim, potentially
disclosing secret information or transferring money without the
victim's authorization.
</quote>
Am I just too stupid or the reasoning is semi-fraudulent in here? So
the "XSS" danger goes as follows:
1) user comes to a trusted (by user) site like his bank account login
page
2) A script on the page - or any other page page after authorization -
uses cross-site scripting technics to get/send chunks of code/data
from other site(s).
3) One of this chunks contains a code to grab some sensitive user
information and to sent it to a 3rd party server.
Conclusion: cross-site capabilities of JavaScript are very dangerous.
Sorry? What does the described situation has anything to do with the
programming language itself? The only real question here is: why the
hey the bank site used code for a malicious site? and did they already
fired the security manager or still waiting for something?
I see here an occasional or an intentional brute force mixture of two
completely different issues:
1) sandbox model vulnerability
2) trust violation
Sandbox model vulnerability
Say there is an object X with method Y and one has found that with
some fancy argument Z : X.Y(Z) one may get access to say local file
system.
That would be clearly a sandbox model vulnerability to claim onto the
particular language engine and to fix a.s.a.p. This way the sandbox
model must guarantee that no matter how the currently executing code
has resulted (from one site or by chunks from 1024 different sites) no
one statement of the code gets any privileges outside of the sandbox
model, however fancy way it would arrive to the interpreter. In this
aspect JavaScript is very robust, so cross-site scripting doesn't
compromise the security.
Trust violation
User came to site X, was prompted to launch <object> X from company Y,
Inc. signed by a recognized certificate authority Z, Inc. User clicked
"OK" and the launched component has formatted his disk C:\ plus left a
nasty message in the root directory.
In this case it is duty of Z, Inc. by user's complain to get sh** out
of Y, Inc. so they would never be in the online business anymore. If
Z, Inc. will not find Y, Inc., then Z, Inc. itself cannot be
considered a trusted authority.
Coming back to the situation listed on Wiki: if user visited a bank
site and her personal info got stolen because the bank site uses 3rd
party script insertions from malicious 3rd parties: then simply don't
trust this bank anymore, it is handled by careless people who don't
care of your money.
site_vulnerabilities">
A common JavaScript-related security problem is cross-site scripting,
or XSS, a violation of the same origin policy. XSS vulnerabilities
occur when an attacker is able to cause a trusted Web site, such as an
online banking website, to include a malicious script in the webpage
presented to a victim. In that example, the script can then access the
banking application with the privileges of the victim, potentially
disclosing secret information or transferring money without the
victim's authorization.
</quote>
Am I just too stupid or the reasoning is semi-fraudulent in here? So
the "XSS" danger goes as follows:
1) user comes to a trusted (by user) site like his bank account login
page
2) A script on the page - or any other page page after authorization -
uses cross-site scripting technics to get/send chunks of code/data
from other site(s).
3) One of this chunks contains a code to grab some sensitive user
information and to sent it to a 3rd party server.
Conclusion: cross-site capabilities of JavaScript are very dangerous.
Sorry? What does the described situation has anything to do with the
programming language itself? The only real question here is: why the
hey the bank site used code for a malicious site? and did they already
fired the security manager or still waiting for something?
I see here an occasional or an intentional brute force mixture of two
completely different issues:
1) sandbox model vulnerability
2) trust violation
Sandbox model vulnerability
Say there is an object X with method Y and one has found that with
some fancy argument Z : X.Y(Z) one may get access to say local file
system.
That would be clearly a sandbox model vulnerability to claim onto the
particular language engine and to fix a.s.a.p. This way the sandbox
model must guarantee that no matter how the currently executing code
has resulted (from one site or by chunks from 1024 different sites) no
one statement of the code gets any privileges outside of the sandbox
model, however fancy way it would arrive to the interpreter. In this
aspect JavaScript is very robust, so cross-site scripting doesn't
compromise the security.
Trust violation
User came to site X, was prompted to launch <object> X from company Y,
Inc. signed by a recognized certificate authority Z, Inc. User clicked
"OK" and the launched component has formatted his disk C:\ plus left a
nasty message in the root directory.
In this case it is duty of Z, Inc. by user's complain to get sh** out
of Y, Inc. so they would never be in the online business anymore. If
Z, Inc. will not find Y, Inc., then Z, Inc. itself cannot be
considered a trusted authority.
Coming back to the situation listed on Wiki: if user visited a bank
site and her personal info got stolen because the bank site uses 3rd
party script insertions from malicious 3rd parties: then simply don't
trust this bank anymore, it is handled by careless people who don't
care of your money.