Chris Shiflett, a PHP developer, writes about web security, HTTP, and web development, including XSS and escaping.
HN links it for web security topics like XSS, though one commenter says its PHP security advice can mislead and points to an IBM post instead.
This is an old idea that is finally coming to fruition.
See a Microsoft paper from 2011 that prominently features cookie isolation [1]. Or a 2012 proposal in Mozilla's bug tracker [2] which resulted in some proof-of-concept code early on, a writeup in 2013 hosted on Github [3]; blogged about independently and contemporaneously by others [4], which hit HN [5].
I've always taken a dim view on cross-domain requests in general [6] and the sprawling set of specifications (like most security headers) us developers have to learn and implement properly to stay one step ahead [7], and am not particularly enthused that this is opt-in instead of a heavy-handed mandate like some other recently-introduced features, the default opt-in is the more-secure but essentially session-destroying version meaning it's guaranteed to encourage a long and impassioned debate about whether Strict or Lax is the preferred balance.
It's fascinating to go way back to ~2006-2008 and read about when CSRF was first starting to be recognized by mainstream evangelists, commentators, developers and decision-makers as a problem instead of a feature of just how the web works.
This article on DarkReading from 2006 [8] was soon after cited by the OWASP wiki [9], Jeff Atwood first wrote about it in 2008 [10] and admitted its sublteness yet seriousness took him by surprise, and yet it's amusing that going back to 2003 you can find references to CSRF by that name and instructions on how to protect against it [11] --…
bash$ diff -u <(curl -s http://leakedin.org) <(curl -s http://leakedln.org)
--- /dev/fd/63 2012-06-07 15:31:02.000000000 +0100
+++ /dev/fd/62 2012-06-07 15:31:02.000000000 +0100
@@ -322,6 +322,7 @@
</noscript>
<form id="leakedin-check" onsubmit="hashIt()">
<fieldset>
+ <input type="text" name="uname" id="uname" placeholder="Type your username here" />
<input autocomplete="off" type="text" name="check" id="check" onblur="hashIt()" placeholder="Type your password here" />
<button type="submit">Check</button>
</fieldset>
@@ -329,7 +330,7 @@
<div id="footer">
<p><a id="fk" href="http://fictivekin.com">Fictive Kin</a> and <a href="http://shiflett.org/">friends</a>.</p>
</div>
-<script src="//static.getclicky.com/js" type="text/javascript"></script>
+<script src="/static.getclicky.com/js" type="text/javascript"></script>
<script type="text/javascript">try{ clicky.init(66595923); }catch(e){}</script>
-<noscript><p><img alt="Clicky" width="1" height="1" src="//in.getclicky.com/66595923ns.gif" /></p></noscript>
+<noscript><p><img alt="Clicky" width="1" height="1" src="/in.getclicky.com/66595923ns.gif" /></p></noscript>
</body>
I think what is normal is to let the company know first.
And also give them a test they can reproduce with the bug
and also a deadline in which you are going to make public the security bug you have done.
The deadline is because many companies ignore the problem until is public.
This opinion comes from reading this Chris Shifflet's article:
http://shiflett.org/blog/2007/mar/my-amazon-anniversary
"On this day last year, I informed Amazon about a pretty serious vulnerability and demonstrated it with a few examples and a detailed description. In the description, I explained how to exploit the infamous "1-Click" feature, causing victims to purchase items of my choosing without their knowledge or consent, and I stressed that the scope of the problem extended beyond my benign examples. After some mild prodding, I finally received a reply letting me know that my email had been received, the vulnerability had been verified, and Amazon considered fixing it a top priority.""
Blog about website design + blog post about website security = Excellent source of well-intended data that perpetuates PHP code that people think is secure
For a better post on securing PHP scripts, see IBM's post at http://www.ibm.com/developerworks/opensource/library/os-php-secure-apps/ or just see http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string to understand why anyone recommending addslashes should be ignored.
I've done this on a couple well-visited client sites and it worked incredibly well. The best part is that it's super easy to add an invisible "email" field to a form and check if it has any content on the backend. By far the best bang for the buck.
I'm fairly sure I first learned this trick from Chris Shiflett's blog[1] a few years back, although I can't seem to find the original post.
1: http://shiflett.org/
I totally agree, except the date one. I feel like many people don't take the time to make their URLs look good.
I do like when I can go to /2008/06 and see all the posts from June.
Here's some more interesting reading on URL design: http://shiflett.org/blog/2008/mar/urls-can-be-beautiful