[Full-disclosure] Pros and cons of 'Access-Control-Allow-Origin' header?

2012-02-22 Thread David Blanc
Does 'Access-Control-Allow-Origin' header provide any benefits in
defending against cross site scripting attacks?

Doesn't 'Access-Control-Allow-Origin' header make any XSS flaw
trivially exploitable? For example, if an attacker finds an XSS flaw
in a web application, he can now inject a JavaScript with
XMLHttpRequest that sends a request to attacker's web server which
serves resources with the HTTP header Access-Control-Allow-Origin:
*. The browser would see this header and fetch the resource from the
attacker's web server.

Isn't the web a safer place without this header?

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Re: [Full-disclosure] Pros and cons of 'Access-Control-Allow-Origin' header?

2012-02-22 Thread David Blanc
I am sorry, I don't understand what you are trying to say here. Which
question of mine did you answer?

BTW, I'm aware that whether we use a wildcard or not is up to us.

On Thu, Feb 23, 2012 at 1:28 AM, Michele Orru antisnatc...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Take a look at http://beefproject.com internals.

 We're using that header.

 Actually it depends how do you use it.
 It's like crossdomain.xml: you can use a wildcard or not,
 it's up to you.

 Cheers
 antisnatchor

 David Blanc wrote:
 Does 'Access-Control-Allow-Origin' header provide any benefits in
 defending against cross site scripting attacks?

 Doesn't 'Access-Control-Allow-Origin' header make any XSS flaw
 trivially exploitable? For example, if an attacker finds an XSS flaw
 in a web application, he can now inject a JavaScript with
 XMLHttpRequest that sends a request to attacker's web server which
 serves resources with the HTTP header Access-Control-Allow-Origin:
 *. The browser would see this header and fetch the resource from the
 attacker's web server.

 Isn't the web a safer place without this header?

 ___
 Full-Disclosure - We believe in it.
 Charter: http://lists.grok.org.uk/full-disclosure-charter.html
 Hosted and sponsored by Secunia - http://secunia.com/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iQEcBAEBAgAGBQJPRUjKAAoJEBgl8Z+oSxe4Gn8H+wTu5HqCgm5md7jZOghFV0c0
 TSgTakNd05x60raj1wNeCXjqE2mqHDvECjJIezlzlDgAx3q2TpagUlzR2iIICc6Y
 25N9CCIkvb6WPqBl3Ee/NYkXPgKb6GDNGzdzNGZtrzZZrvOP3Dy6MCvw6RxwjcWo
 DtAzvHd4tAktRMfOpE61ICwyXOl5dCER4a/ai3DolN7O5xJvv0SsB3qgBF+4++pJ
 XhuQC9WA3j9994k9n9x4NGqJBZUE7vvfTIZR3T85BgcY8YiJgOHTmarMF7Fb6kHB
 mSLEVLWE1bY3aMKN7+SPjnkS7LZeCoMnhmXEQ2jcWCPUBQpv/hzjq6hgduOSoes=
 =xNpJ
 -END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


[Full-disclosure] Is FD no longer unmoderated?

2011-11-30 Thread David Blanc
A colleague of mine subscribed to FD recently and tried posting to it
but every time he gets this message:

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post to moderated list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.

But the message neither gets posted, nor does he ever gets the
moderator's decision in a notification? What's the matter? Since when
is this list moderated?

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


[Full-disclosure] FFSpy Buster : Duarte Silva announces that the security of most software allowing plugins such as vim, emacs, gnome, eclipse, etc. is flawed

2009-05-29 Thread David Blanc
Duarte Silva, the creator of the so-called FFSpy PoC seems to be
suggesting that the plugin mechanism of most software which allows a
user to run a plugin in the context of the user running the software
is flawed.

First of all, here is the lame PoC for those who want to read it:
http://myf00.net/?p=18 You can see a few comments where people are
trying to ask how exactly the attack is carried out. However, Duarte
has been giving lame responses such as: True. But is also interesting
to see that there isn’t nothing to ensure the user the plug-in isn’t
changed.

In his wrap up blog at http://myf00.net/?p=97 he seems to suggest that
the existing plugin or add on mechanism of most software is flawed. Do
read his comments at the end of the blog.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Re: [Full-disclosure] FFSpy, a firefox malware PoC

2009-05-26 Thread David Blanc
On Tue, May 26, 2009 at 8:38 PM, Shell Code technobus...@gmail.com wrote:
 I would appreciate if you post replies to the list instead of sending
 it only to me. My comments inline.

 On Tue, May 26, 2009 at 5:10 PM, saphex sap...@gmail.com wrote:
 I fail to understand what is new or interesting in this POC. If a
 person with malicious intent gains so much access to a system that he
 can put his files or firefox plugins, modify existing files, etc

 If you gain access to a system with the user that isn't administrator
 (at least under systems that enforce user *differentiation*, read any
 Linux flavour and Vista), you only have access to the users folder,
 you can't install anything (especially under Linux). I guess this is
 meant to be an alternative way of getting the job done.

 This is not true. You can carry out attacks of the same severity by
 gaining access to a Linux or Windows system as a user that isn't the
 administrator. Here are a few examples:

 1. Modify a vim, emacs, KDE, GNome, etc. plugin that the user uses so
 that it sends user's personal content (data, files, commands executed,
 etc.) from the system to a remote server.

 2. Put a malicious executable file or script in the user's home
 directory and execute it from start up scripts (.bashrc,
 .bash_profile, etc.) so that the malicious executable file executes
 whenever the user logs in. Now this malicious file can send user's
 personal content to a remote server.

 3. Modify or put plugins for other software to malicous stuff. Similar
 to point 1.

 4. Override PATH settings, aliases, put scripts, etc. so that when the
 'ls' now executes 'rm' or some other malicious command so that user
 ends up executing commands he did not intend to.

 5. ... and much more ...


 From the POC it seems that somehow the attacker has to gain physical
 access to the system or do some social engineering attack to fool the
 user in installing or modifying his existing plugins. The PoC does not
 explain how this is done.

 To you know the download and execute payload for exploits? Make an
 application that changes the files, then use that payload in some
 exploit. People just want everything done. Just click, download, use,
 and call them self l33ts .


 How is it any different from the attack scenarios I have explained in
 case of vim, emacs, KDE, GNome, Linux shell, etc.?

 Maybe this is nothing new, but I think that the way to do it is new.
 Because you don't install anything, and the point to be proven here is
 that Firefox add-on system is security flawed from the very beginning.

 So, are you saying vim, emacs and the plugin system of every other
 software on the earth is security flawed from the very beginning?


I believe saphex or the author of the so-called-PoC, Duarte Silva do
not understand the concept of privileges and security vulnerabilities.
By the way, are saphex and Duarte Silva two different persons or
saphex == Duarte Silva?

Coming back to the topic of privileges, any Firefox addon runs in the
context of the user running the browser. So, the addon can do whatever
the user running the browser can. The same holds true for plugins of
other software too as Shell Code has correctly explained. For example,
an emacs plugin can do whatever the user running the emacs can.

So, if saphex or Duarte Silva argues that this is a security flaw in
Firefox addon mechanism, they will also argue that this is a security
flaw in emacs, Windows, Eclipse and every other OS and software. Such
an argument, without any doubt, is lame and stupid as most people
trained in computer security would agree.

--
Only two things are infinite, the universe and human stupidity, and
I'm not sure about the former. -  by Albert Einstein.
--

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/