nbpoole

http://php.net/manual/en/security.database.sql-injection.php

> (E) telephone or instrument number or other subscriber number or identity, including any temporarily assigned network address; and

http://www.law.cornell.edu/uscode/18/usc_sec_18_00002703----...

The new law explicitly amends the previous law so that IP address records are stored for 18 months, as opposed to 90 days.

---

(a) In General- Section 2703 of title 18, United States Code, is amended by adding at the end the following:

`(h) Retention of Certain Records- A provider of an electronic communication service or remote computing service shall retain for a period of at least 18 months the temporarily assigned network addresses the service assigns to each account, unless that address is transmitted by radio communication (as defined in section 3 of the Communications Act of 1934).'.

(b) Sense of Congress- It is the sense of Congress that records retained pursuant to section 2703(h) of title 18, United States Code, should be stored securely to protect customer privacy and prevent against breaches of the records.

---

In other words, it amends the existing language [0] which says (in part):

---

A provider of electronic communication service or remote computing service shall disclose to a governmental entity the—

(A) name;

(B) address;

(C) local and long distance telephone connection records, or records of session times and durations;

(D) length of service (including start date) and types of service utilized;

(E) telephone or instrument number or other subscriber number or identity, including any temporarily assigned network address; and

(F) means and source of payment for such service (including any credit card or bank account number),

of a subscriber to or customer of such service when the governmental entity uses an administrative subpoena authorized by a Federal or State statute or a Federal or State grand jury or trial subpoena or any means available under paragraph (1).

[snip]

(f) Requirement To Preserve Evidence.—

(1) In general.— A provider of wire or electronic communication services or a remote computing service, upon the request of a governmental entity, shall take all necessary steps to preserve records and other evidence in its possession pending the issuance of a court order or other process.

(2) Period of retention.— Records referred to in paragraph (1) shall be retained for a period of 90 days, which shall be extended for an additional 90-day period upon a renewed request by the governmental entity.

---

So you're 100% right: the name, address, etc information is ALREADY being preserved. This legislation mandates that records of IP addresses linked to accounts be stored for at least 18 months, whereas before they would have been retained for 90-180 days.

---

[0]: http://www.law.cornell.edu/uscode/18/usc_sec_18_00002703----...

https://twitter.com/#!/dakami/status/98910873044791297

At best, a bounty program gives me the incentive to look more closely at a particular website / application. But I've submitted plenty of vulnerability reports to companies that don't have bounty programs.

What this bounty really means: if you like finding and responsibly reporting security vulnerabilities, you now have one more reason to spend time doing so on Facebook.

[Note: I've participated in the bounty programs for Google, Mozilla, and CCBill. I've submitted security vulnerabilities to Facebook as well prior to this bounty program]

Tested on MySQL 5.5 on OS X:

    mysql> use test
    Database changed

    mysql> show tables;
    Empty set (0.00 sec)

    mysql> create table test (id int(10) unsigned not null auto_increment, name varchar(10), primary key(id));
    Query OK, 0 rows affected (0.13 sec)

    mysql> insert into test (name) values ("Bob");
    Query OK, 1 row affected (0.02 sec)

    mysql> select * from test;
    +----+------+
    | id | name |
    +----+------+
    |  1 | Bob  |
    +----+------+
    1 row in set (0.00 sec)

    mysql> select * from test WHERE (select * FROM test) = 1;
    ERROR 1241 (21000): Operand should contain 2 column(s)

    mysql> select * from test WHERE (select 1 FROM test) = 1;
    +----+------+
    | id | name |
    +----+------+
    |  1 | Bob  |
    +----+------+
    1 row in set (0.00 sec)

    mysql> insert into test (name) values ("Frank");
    Query OK, 1 row affected (0.00 sec)

    mysql> select * from test WHERE (select 1 FROM test) = 1;
    ERROR 1242 (21000): Subquery returns more than 1 row

    Error Based:
        AND (SELECT * FROM SOME_EXISTING_TABLE) = 1

"For a comparison of the subquery to a scalar, the subquery must return a scalar."

It's easy to fix: just add LIMIT 1 to the end of the sub-select.

---

This document is very useful. I've been doing web app security for a while and I haven't run across some of these techniques before (eg: PROCEDURE ANALYSE()). I didn't realize that PDO_MYSQL allowed for multiple queries by default either (although it makes sense, since historically other RDBMS have supported it).

From the blog post:

"I do exist. I am a real person using a nickname my parents stuck me with long ago. I do not work for the hotel industry, though I admit I love a Four Seasons as much as the next girl. Oh and on that note, I am female."

Sounds like a woman to me.

If you're interesting in reading more, there's some good discussion at http://news.ycombinator.com/item?id=2606096

One of the code examples from here might be good if you're looking to scare people :-P

Edit: I have a more serious suggestion. Why not pick 8 lines from your own codebase?

- http://checkout.google.com/support/sell/bin/answer.py?answer...

- https://payments.amazon.com/sdui/sdui/helpTab/Amazon-Simple-...

- http://letsearndollar.blogspot.com/2009/07/change-any-paypal...

"The Tech Model Railroad Club (TMRC) is a student organization at the Massachusetts Institute of Technology (MIT), and one of the most celebrated model railroad clubs in the world, because of its historic role as a wellspring of hacker culture."

It was posted in 2009, so the comments are probably closed :-)

I fundamentally disagree with you though. For me, notices are very useful for identifying typos and other coding mistakes that can lead to incorrect behavior.

Consider the following lines of code:

    $user_info = array(
            'id'            => 1,
            'username'      => 'nbpoole',
            'is_guess'      => false
    );

    if (!$user_info['is_guest'])
    {
            echo 'Member stuff';
    }

For anyone who's curious, here's a list of the changes in 5.4 alpha 1: http://www.php.net/releases/NEWS_5_4_0_alpha1.txt

http://www.php.net/archive/2011.php#id2011-06-28-1

It's in PHP 5.4 alpha as well ;)

1. Detecting XSS by looking for '<', '>', '(', or ')' in the URL is a very naive approach. It can be bypassed fairly easily and many XSS vectors could have payloads constructed that bypass this filter. Also, you're likely to get some false positives for a certain subset of applications, since parenthesis have legitimate uses.

2. I'm not sure on what basis the first part of the CSRF protection is valid or what it's trying to protect. Is it looking for an Accept header for application/json?

3. The second part of the CSRF protection, which looks at the referer header, seems buggy and easy to bypass. What is it trying to accomplish? Right now, it seems like it blocks POST requests where the referer is set and contains the server's hostname (which valid requests will have).

4. Detecting CSRF by looking for non-GET/POST methods is a bad idea unless your application specifically constrains itself to those two methods. Many modern applications are using PUT and DELETE internally for routing purposes.

5. Detecting LFI in the URL by looking for ../ is, again, naive (although less likely to lead to false positives than the XSS testing).

6. The most "objectionable" part here seems to be the "fight back" options. There are definitely some legitimate concerns about an attacker being able to get a targeted user banned from a site (after all, you can't distinguish between a failed CSRF that an attacker is sending and a failed CSRF that an attacker tried to convince a target to send). For the most part though, I don't think they're a big deal for a small, independent site that opts-in to them: they sound a lot like the Miserable Users mod for VB (http://www.vbulletin.org/forum/showthread.php?t=93258)

That being said, no system that operates like a WAF is going to be perfect. The idea of a mod_security-like system for node.js is very cool though. I just think the way you tried to launch it here, with no indication on GitHub or otherwise that it's not a finished product, has led to some backlash. :-)

Try searching for "google report security" or "security vulnerability google" and you'll find the right information.

There was some helpful Q&A in that old discussion though, so it's good that you linked to it.

http://news.ycombinator.com/item?id=2719028

Apparently they don't run their security scanner against their own website ;-)

"Security measures have been built into the design and setup of our infrastructure." tells you absolutely nothing. Neither does "Disasters are never nice events and we hope they don’t happen. We also expect one will happen and have plans to recover when it does." (although it's not strictly a security issue either).

https://twitter.com/#!/ruxum/status/86827701381496833

In other words, https://secure.trust-guard.com/certificates/www.ruxum.com

Personally, I don't consider that to be "Wall Street-Level Security."

https://twitter.com/#!/noptrix/status/91910866538217472

And the HN discussions about the previous vulnerability: http://news.ycombinator.com/item?id=2522466 and http://news.ycombinator.com/item?id=2522453