どこが悪いかを、11回で突き止める — 本文を半分ずつ切る

1500文字の本文のどこか1か所が、遮断の仕組みに引っかかっています。どこかは教えてもらえません。

読んで探すのは諦めました。代わりに、半分ずつ削って試す作業を11回やりました。

読んで探すと、範囲が減らない#

最初は目で探しました。怪しそうな行を眺めて、直して、投げる。落ちる。また眺める。

この方法の問題は、1回試しても候補が減らないことです。「これは違った」が1つ分かるだけで、残りは全部そのままです。

1500文字から1文字まで絞るのに、前者だと最悪1500回。後者なら11回です。

半分に切って投げる#

手順は単純です。

実際の減り方はこうなりました。

試す作業を、1行で済むようにした#

11回とはいえ、毎回やることがあります。下書きを作って、結果を見て、作られた下書きを消す。手でやると1回2分かかります。

そこで、ブラウザの中に確かめるための小さな仕組みを置きました。やっていることは3つだけです。

これで1回が数秒になりました。11回を苦にしないための準備が、結果としていちばん効いています。

引き金が2つあると、手順が嘘をつく#

ここで一度つまずきました。前半を送っても落ちる。後半を送っても落ちる。どちらにもあるということです。

半分に切る手順は、原因が1つだけという前提で動いています。2つあると、どちらへ進んでも落ちるので、絞り込みが止まります。

やったのは、前半だけで最後まで絞り切って、見つけた1つを取り除いてから、もう一度全体で始めることでした。2周目で2つめが出てきます。

見つかったのは、2つの短い並び#

結果として、引っかかっていたのはたった2種類の文字の並びでした。どちらもプログラムを書くうえではありふれた形です。

片方は、文字列を囲むために使う記号を対で使ったときだけ反応しました。1つだけなら通ります。もう片方は、ある命令の名前に括弧が続いた形です。引用符で囲んでも、囲まなくても落ちました。

どちらも、攻撃に使われる形と見分けがつきません。判定している側は正しく仕事をしています。こちらが普通のコードを書いているだけです。

今回の学び#

まず、1回で候補が半分になる方法を選ぶということ。怪しい所を直す方法は、1回試しても候補が1つしか減りません。同じ11回で、1500文字から1文字まで届くかどうかが変わります。

次に、絞り込む作業は、中身を理解していなくても進むこと。判断材料は「通ったか落ちたか」だけでした。読んで探す方法は自分が気づける範囲しか探せないので、見慣れた書き方が原因だと永久に見つかりません。

そして、原因が1つという前提を疑うこと。両側とも落ちるのは手順の失敗ではなく、2つあるという情報です。片方を取り除いてからやり直すと進みました。