canspice.org

Short answer: When it’s a JavaScript
arguments
object.

Long answer:

In a JavaScript package I’m writing, I have a function that returns an object.
There’s a bug in it where in certain situations it returns the JavaScript value
true.

I have a test framework set up with Mocha using the Chai assertion library. With
it, I can do

1

expect(result).to.eql(expected);

This means that the result I get back from my function should deeply equal the
expected value. “Deeply equal” means that the objects being compared are
identical — they’re the same type of object and store the same information.

In JavaScript, one would not expect an
Array to be deeply equal to an Object
because they’re different types of objects.

But in the Chai assertion library, an empty Array is deeply equal to an empty Object. This assertion passes when it shouldn’t:

1

expect({}).to.eql([]);

Similarly, but even more confusingly, both an empty Array and an empty Object
are considered to be deeply equal to the JavaScript true value:

1
2

expect(true).to.eql({});
expect(true).to.eql([]);

Both of these assertions pass.

When I was writing a test to ensure that my function wasn’t returning true,
but instead should be returning {}, I was expecting the assertion to fail. It
didn’t.

Since Chai is open source, I forked it, patched it, and submitted a pull request
to get the fix into the main Chai repository. It makes sure that when deep
equality is done, the types of both objects have to be the same.

This was over a month ago, and my pull request hasn’t been accepted.

Why? Because of
arguments.

See, JavaScript has a builtin arguments object, which is “Array-like” in that
it’s an ordered list of values. When you call a function, it’s the list of
arguments that you passed to that function:

1
2
3
4
5

function dumpArgs() {
    for (var i = 0; i < arguments.length; i++) {
        console.log(i + " : " + arguments[i]);
    }
}

This object is kind of like an Array, but the only Array method you can call on it is
length. It’s not an Array object, it’s an Arguments object.

I’m of the opinion that “deeply equals” means that if the objects are different,
they’re not deeply equal. The string "4" might look like it contains the same
value as the integer 4, but you wouldn’t expect them to be deeply equal, because
they’re different types of objects.

My patch hasn’t been pulled because the guy doing the pulling disagrees, which
you can see at the pull request comments. But
only for non-primitive types. “4” is still not deeply equal to 4, but if
arguments is [1,2,3] then that’s equal to the Array [1,2,3].

The Mozilla Developer Network docs say

The arguments object is not an Array. It is similar to an Array, but does not
have any Array properties except length. For example, it does not have the pop
method. However it can be converted to a real Array.

I could change my patch so that if the arguments object is one of the values
being tested, it could be converted to a real Array before doing the check, but
that goes against the concept of deep equality. Two objects of different types
shouldn’t be deeply equal.

So if you’re using the Chai assertion library, and you discover that an empty
Array is equal to true, you’re getting that result because one of the Chai
developers thinks that deeply equals is only applicable some of the time,
because it’s “subtle”.

In part one of this saga I described how CIBC had sent me a text with a phone number to get them to call them, and how this is wrong.

I just went through my spam folder and found this gem:

Dear BradCavanagh,

Please contact us as soon as possible at 1-866-454-4339 (in Canada & U.S.) or 416-785-1331 (from elsewhere) to verify recent transactions on your CIBC Credit Card Account ending in XXXX.

We will also be phoning you at the primary number that we have on file for you with this message.

We are available by phone 24 hours a day, 7 days a week.

Please do not reply to this e-mail.

If you received this message in error, please send an e-mail to feedback@cibc.com.

Sincerely,
CIBC

I’d like to quote from CIBC’s email and text message fraud page:

Phishing emails and text messages are often sent out as spam to numerous recipients and appear to come from legitimate businesses, sometimes even duplicating legitimate logos and text. Within a phishing email, you may be requested to click on a link that takes you to a fraudulent site or pop-up window where you are asked to submit personal and financial information. A phishing text message may request that you send personal information back to
the sender through text message or call a phone number.

In order to increase the chances of a response, messages may imply a sense of urgency or an immediate risk to bank accounts or credit cards if you fail to answer. Special offers and prizes may also be promoted as incentives.

I’ve bolded all of the ways that CIBC’s email falls under CIBC’s own definition of phishing.

CIBC, you’re still doing it wrong.

This morning I received a text message purporting to be from CIBC:

BRAD,¡
Please call CIBC at 1-866-454-4339 to verify recent transactions on your credit card ending in¡XXXX.

Yes, the ¡s were part of the text message, and I’ve X’ed out the last four digits in my credit card.

This text came from the number “242-222”. I signed up for CIBC alerts via text message, and they’ve all come from this number, but there’s nothing guaranteeing that CIBC did in fact text me to get me to call them. In fact, if you search for 1-866-454-4339, you don’t get any CIBC webpages in your results.

It’s very nice that CIBC has this service. It was actually a legitimate request, as someone ordered over $1000 worth of stuff from walmart.com using my credit card.

But CIBC is doing it wrong. There is nothing on this text message verifying that this is actually CIBC. Sure, they get the last four digits of my credit card right, but those are all over the place, and they’re not considered to be sensitive data, which means that vendors do not need to do anything special to store them. It would be rather trivial to get the last four digits of my credit card number, my name, and my phone number, and then send a spoofed SMS. If I were naive, I’d call the number listed in the text message, tell them my full credit card number, and they’d be off to the races.

Never trust a text message, voicemail, or email that asks you to call a random phone number to verify any sort of personal information. Never. Always call a number that you know for a fact is linked with the company in question. For CIBC, you can either look at the back of your credit card or look up customer contact numbers on their website.

What CIBC should do is change their text message to read:

BRAD, please call CIBC Credit Card Services at the number listed on the back of your Visa card to verify recent transactions on your card ending in XXXX.

It’s a simple change but one that would help make people less likely to fall for phishing attacks.

CIBC should also list the 1-866-454-4339 number on their website, proving that it is actually a CIBC number. I didn’t call that number because there’s no way of verifying that it’s actually CIBC.

In fact, this text message raises all kinds of red flags that CIBC themselves ask you to watch out for:

A phishing text message may request that you send personal information back to the sender through text message or call a phone number.

In order to increase the chances of a response, messages may imply a sense of urgency or an immediate risk to bank accounts or credit cards if you fail to answer.

CIBC Credit Card Fraud Department, you’re doing it wrong. Even according to your own website.

Update: But wait, there’s more!

If you upgrade Elasticsearch from 0.20 to 0.90, any queries you previously made
using a front slash will fail with an error similar to:

1
2
3
4
5
6
7
8
9
10
11

"error" : "SearchPhaseExecutionException[Failed to execute phase [query],
  total failure; shardFailures {[tJ5MGSY_RnOHfeAN2O8gnQ][twitter][2]:
  SearchParseException[[twitter][2]: from[-1],size[-1]: Parse Failure [Failed to
  parse source [{\n   \"query\":{\n      \"query_string\":{\n
  \"query\":\"user:kimchy/banon\"\n      }\n   }\n}]]]; nested:
  QueryParsingException[[twitter] Failed to parse query [user:kimchy/banon]];
  nested: ParseException[Cannot parse 'user:kimchy/banon': Lexical error at line
  1, column 18.  Encountered: <EOF> after : \"/banon\"]; nested:
  TokenMgrError[Lexical error at line 1, column 18.  Encountered: <EOF> after :
  \"/banon\"]; }{[tJ5MGSY_RnOHfeAN2O8gnQ][twitter][0]:
  ...

If you’re like me, you’re thinking “but my query doesn’t have an EOF in it, it’s
valid JSON”, and you’d be right. Your query is still valid JSON, but it’s no
longer a valid Elasticsearch query.

When Elasticsearch moved from 0.20 to 0.90, they changed versions of Lucene as
well, going from 3 to 4. Under Lucene 4, a query with a slash in it is
interpreted as a regular expression. Your regular expression starts with the
slash, but if you only have one slash, it never ends, so you get the
Encountered: <EOF> after : error.

You will need to convert your queries to escape out slashes. Thus, a 0.20 query
of:

1
2
3
4
5
6
7

{
   "query":{
      "query_string":{
         "query":"user:kimchy/banon"
      }
   }
}

…becomes this under Elasticsearch 0.90:

1
2
3
4
5
6
7

{
   "query":{
      "query_string":{
         "query":"user:kimchy\\/banon"
      }
   }
}

Note that this only affects queries; filters are seemingly unaffected.

This was raised in this Github issue.