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.

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.