Comments for Insecure Web http://insecureweb.com Insight into web application security Wed, 16 Dec 2009 01:02:49 -0800 http://wordpress.org/?v=2.8.5 hourly 1 Comment on Secure yourself from the recent PDF exploits by disabling JavaScript by Zero-Day Malware Drops Payloads Signed with a Forged Microsoft Certificate « Webroot Threat Blog http://insecureweb.com/javascript/secure-yourselffrom-the-recent-pdf-exploits-by-disabling-javascript/comment-page-1/#comment-68 Zero-Day Malware Drops Payloads Signed with a Forged Microsoft Certificate « Webroot Threat Blog Wed, 16 Dec 2009 01:02:49 +0000 http://insecureweb.com/?p=85#comment-68 [...] the meantime, until Adobe issues updates for Acrobat and/or Reader, you may wish to follow these instructions to disable Javascript within those [...] [...] the meantime, until Adobe issues updates for Acrobat and/or Reader, you may wish to follow these instructions to disable Javascript within those [...]

]]> Comment on Secure yourself from the recent PDF exploits by disabling JavaScript by Sean http://insecureweb.com/javascript/secure-yourselffrom-the-recent-pdf-exploits-by-disabling-javascript/comment-page-1/#comment-67 Sean Tue, 15 Dec 2009 15:58:24 +0000 http://insecureweb.com/?p=85#comment-67 Thanks for the registry file and for including all current versions, I use PolicyMaker here and this makes it really simple to push the registry updates. Adobe's security on this javascript stuff is just cheesecloth. Why we need yet another webpage when actually we need a secure way of passing documents eludes me at the moment. Thanks for the registry file and for including all current versions, I use PolicyMaker here and this makes it really simple to push the registry updates. Adobe’s security on this javascript stuff is just cheesecloth. Why we need yet another webpage when actually we need a secure way of passing documents eludes me at the moment.

]]> Comment on Secure your Ajax requests with jQuery by Andy http://insecureweb.com/javascript/secure-your-ajax-request-with-jquery/comment-page-1/#comment-63 Andy Sun, 04 Oct 2009 10:37:10 +0000 http://www.insecureweb.com/?p=26#comment-63 Thanks for this very simple yet genius idea. I've been worried about xss attacks myself and had almost given up hope of finding a solution. I actually found this article while searching for a way to encrypt a login request to guard against sniffing. Glad I stumbled here and found an answer to a question I thought unanswerable. Cheers Bryan! You're a star Thanks for this very simple yet genius idea.
I’ve been worried about xss attacks myself and had almost given up hope of finding a solution.

I actually found this article while searching for a way to encrypt a login request to guard against sniffing. Glad I stumbled here and found an answer to a question I thought unanswerable.

Cheers Bryan! You’re a star

]]> Comment on HTTP Methods: GET vs POST by Bala Sakthis http://insecureweb.com/web-security/http-methods-get-vs-post/comment-page-1/#comment-57 Bala Sakthis Mon, 13 Jul 2009 01:24:45 +0000 http://www.insecureweb.com/?p=22#comment-57 Hi Bryan, I went through your article. A crisp explanation with the header data. "In C# there exists an object called Request which provides all of the details of a given request....." After reading the above para, I wanted to share one of the whitepapers, I went through. Please visit http://lavakumar.com/ and read the article on "Split and Join". Also, please google and learn about HTTP Parameter pollution. This vulnerability has its base on what you had warned. Thanks! Bala Hi Bryan,
I went through your article. A crisp explanation with the header data.

“In C# there exists an object called Request which provides all of the details of a given request…..”

After reading the above para, I wanted to share one of the whitepapers, I went through. Please visit http://lavakumar.com/ and read the article on “Split and Join”. Also, please google and learn about HTTP Parameter pollution. This vulnerability has its base on what you had warned.

Thanks!
Bala

]]> Comment on Secure yourself from the recent PDF exploits by disabling JavaScript by Bryan Migliorisi http://insecureweb.com/javascript/secure-yourselffrom-the-recent-pdf-exploits-by-disabling-javascript/comment-page-1/#comment-52 Bryan Migliorisi Fri, 01 May 2009 03:34:16 +0000 http://insecureweb.com/?p=85#comment-52 @leftystrat Thanks :) You can also try FoxIt which is another free PDF reader for Windows. http://www.foxitsoftware.com/pdf/reader/ @leftystrat Thanks :) You can also try FoxIt which is another free PDF reader for Windows.

http://www.foxitsoftware.com/pdf/reader/

]]> Comment on Secure yourself from the recent PDF exploits by disabling JavaScript by leftystrat http://insecureweb.com/javascript/secure-yourselffrom-the-recent-pdf-exploits-by-disabling-javascript/comment-page-1/#comment-51 leftystrat Fri, 24 Apr 2009 22:29:23 +0000 http://insecureweb.com/?p=85#comment-51 I read yesterday that people are starting to recommend using alternatives to Acrobat. I avoid Adobe wherever possible personally but get stuck with it sometimes at work. Sumatra is a free reader app for Windows that works quite well (and doesn't phone home). Linux generally comes with its own. It has been my experience that very little good comes from javascript in a browser. Now I have to worry about it in Acrobat too. Bravo on the GPO/registry file! I read yesterday that people are starting to recommend using alternatives to Acrobat. I avoid Adobe wherever possible personally but get stuck with it sometimes at work. Sumatra is a free reader app for Windows that works quite well (and doesn’t phone home). Linux generally comes with its own.

It has been my experience that very little good comes from javascript in a browser. Now I have to worry about it in Acrobat too.

Bravo on the GPO/registry file!

]]> Comment on An Introduction to Web Application Security by Justin Klein Keane http://insecureweb.com/web-security/an-introduction-to-web-application-security/comment-page-1/#comment-25 Justin Klein Keane Wed, 04 Mar 2009 22:38:37 +0000 http://www.insecureweb.com/?p=8#comment-25 Request parameters actually extend far beyond GET and POST and these other request parameters are often overlooked by developers. For instance, http-referer and browser are user supplied parameters that are often used by logging mechanisms in web applications without developers ever realizing that malicious users can alter these parameters to include SQL injections, Cross Site Scripting (XSS) designed to attack admins viewing log reports, and other nastiness. Cookies are another source of malicious content that developers rarely consider. Every piece of user supplied data can be manipulated quite easily by attackers with tools like WebScarab, Paros, and the Firefox Tamper Data plugin. It's important to sanitize all of this data before processing it. What you describe is also an element of Cross Site Request Forgery (CSRF or Sea-Surf) that can be prevented by injecting pseudo random hidden tokens into forms. This strategy can be used to insure that form POSTs are actually being generated by authenticated users. Web systems record tokens when they generate the forms, and then only process form POSTs if they're accompanied by the relevant token. Making tokens time sensitive is also a good idea (i.e. they time out after an hour). Needless to say a good random generation algorithm is essential so these token's can't be predicted. Request parameters actually extend far beyond GET and POST and these other request parameters are often overlooked by developers. For instance, http-referer and browser are user supplied parameters that are often used by logging mechanisms in web applications without developers ever realizing that malicious users can alter these parameters to include SQL injections, Cross Site Scripting (XSS) designed to attack admins viewing log reports, and other nastiness. Cookies are another source of malicious content that developers rarely consider. Every piece of user supplied data can be manipulated quite easily by attackers with tools like WebScarab, Paros, and the Firefox Tamper Data plugin. It’s important to sanitize all of this data before processing it.

What you describe is also an element of Cross Site Request Forgery (CSRF or Sea-Surf) that can be prevented by injecting pseudo random hidden tokens into forms. This strategy can be used to insure that form POSTs are actually being generated by authenticated users. Web systems record tokens when they generate the forms, and then only process form POSTs if they’re accompanied by the relevant token. Making tokens time sensitive is also a good idea (i.e. they time out after an hour). Needless to say a good random generation algorithm is essential so these token’s can’t be predicted.

]]> Comment on Newish web-based PDF attack in the wild (with real exploit code) by Mauvis http://insecureweb.com/javascript/newish-web-based-pdf-attack-in-the-wild-with-real-exploit-code/comment-page-1/#comment-20 Mauvis Fri, 27 Feb 2009 20:10:14 +0000 http://insecureweb.com/?p=71#comment-20 Thanks for the heads up! Thanks for the heads up!

]]> Comment on About InsecureWeb by Natraj.kanoor http://insecureweb.com/about-insecure-web/comment-page-1/#comment-17 Natraj.kanoor Wed, 25 Feb 2009 02:34:09 +0000 http://www.insecureweb.com/?page_id=2#comment-17 Wonderful . .. . .Great blog lol . . .. .Keep Rocking Wonderful . .. . .Great blog lol . . .. .Keep Rocking

]]> Comment on Newish web-based PDF attack in the wild (with real exploit code) by russian http://insecureweb.com/javascript/newish-web-based-pdf-attack-in-the-wild-with-real-exploit-code/comment-page-1/#comment-16 russian Wed, 25 Feb 2009 02:08:45 +0000 http://insecureweb.com/?p=71#comment-16 its old exploits, 1. Acrobat Reader v.8.1.1 Collab.collectEmailInfo() JavаScript Overflow 2. Acrobat Reader v.8.1.2 Util.printf() JavаScript Overflow its old exploits,

1. Acrobat Reader v.8.1.1 Collab.collectEmailInfo() JavаScript Overflow
2. Acrobat Reader v.8.1.2 Util.printf() JavаScript Overflow

]]>