😎Summary😎

🦜コメントアウトや標準出力の利用であっても、プログラム内ではできるだけ英数字以外の文字を使わないようにしましょう🦜

🫶Notice🫶

ソースコードはGitHubより取得できます(単一.pyファイル)

👾↓のREADMEにこの記事と全く同じことが書かれています👾
https://github.com/myon-bioinformatics/AttentionToJapaneseBeginners

コマンド

python main.py

🚴‍♀️(JSP)

アルファベットじゃない文字を使うとそれが原因で問題が起こることがあります。
今回は、Shift_JISがエンコードもしくはデコードされた時を例にします。
ちなみにこのプログラム(main.py)は成功例のため、問題は基本的に起こりません。

😖Cause & 😆Countermeasures

😖Cause

🚴‍♀️(JSP)

🤖以下がその原因です🤖☞

見かけ上は1つの文字であっても、実際には2バイト以上であることが原因で問題が起こることがあります。
Shift_JIS（SJIS、cp932）の文字コードでは、2バイト目が0x5cの「\」（バックスラッシュ）を含む文字が代表的です。
広義の意味では、2バイト目が0x7cの「|」（パイプ文字）や、2バイト目が正規表現などのメタ文字と重なる文字も含みます。

🍮at length🍮

🚴‍♀️(JSP)

例えば、「能」という文字の2バイト目は「\」です。
それは行末に「\」と書かれていることと同義になります。
C言語では、これによって次の行までがコメントアウトされてしまいます。

Example include those with a second byte of "\"(0x5c)

表: b'\x95\\'
能: b'\x94\\'
十: b'\x8f\\'

😆Countermeasures

🚴‍♀️(JSP)

🥷解決策は意外と単純🥷

コメントアウトの文末に"."(ピリオド)などをつける: 「簡単」
エンコード/デコード時の文字コードを「UTF-8」などにする: 「通常」
そもそも英数字以外はできるだけ使わない: 「重要」

📝The Result of Standard Output📝

🚴‍♀️(JSP) ☕️以下の例はmain.pyを実行した時の成功例の結果です☕️

----------------
Called function: standard_output_harmless_shift_jis
る: b'\x82\xe9'
た: b'\x82\xbd'
記: b'\x8bL'
〆: b'\x81Y'
能.: b'\x94\\.'
a: b'a'
1: b'1'
----------------
Called function: standard_output_harmful_shift_jis
表: b'\x95\\'
能: b'\x94\\'
十: b'\x8f\\'
法: b'\x96@'
充: b'\x8f['
型: b'\x8c^'
施: b'\x8e{'
倍: b'\x94{'
本: b'\x96{'
図: b'\x90}'
----------------
Called function: print_harmless_shift_jis
No problem!!
----------------
Called function: print_harmful_shift_jis
No problem!!

Warning If a problem were occured, "print("No problem!!") at Called function: print_harmful_shift_jis" wouldn't function.

Addendum

🚴‍♀️(JSP)

⚠️「main_to_shift_jis.py」は、「main.py」をUTF-8ではなくShift_JISでエンコードしたファイルです。

🧁Mojibake in detail🧁

🤥main.py🤥

easy_separator = easy_separator_closure()() #これはクロージャという機能

😵‍💫main_to_mojibake.py(Even the Japanese speaker can't read)😵‍💫

easy_separator = easy_separator_closure()() #繧ｯ繝ｭ繝ｼ繧ｸ繝｣繧剃ｽｿ逕ｨ縺励◆

🚴‍♀️日本語話者に向けて

はじめに

日本語をコメントや標準出力等で利用してる方向けへの説明なので、どちらかといえばコードよりもこちらの説明が本題かもしれませんね。

今回はコメントアウトの種類(# or """ """)とは関係ないPythonで実装したので、見かけ上は問題ないように見えます。

昔に比べると見かける機会が減りましたが、「繧ｯ繝ｭ繝ｼ繧ｸ繝｣繧剃ｽｿ逕ｨ縺励◆」のような文字化けを目にしたことはございますか？

こうした理解できない変換の原因の一つには、上に挙げた文字コードの違い(Shift_JISなど)に変換されたときに生じることがあります。

一番伝えたいこと

もちろん、正しい文字が反映されてない問題も気にすべきことなのですが、挙動が変わるのは視覚的の影響のみとは限りません。

今回のレポジトリで最も強く伝えたいことはコメントアウトの英数字以外の文字が影響して挙動が変更することがあるということです。

以下のような事例があります。

ポケットモンスター「赤」「緑」における裏技(バグ)
「この行のコメントを消すとなぜかわからないけど動かなくなる」という現象
エスケープ処理をしたはずのコードに発見された脆弱性(一部の事例)

こうした事例の原因の一つにコメントアウトが英数字以外だったというケースがあります。

また、フロントエンド、バックエンドなど関係なく以下のコメントアウトを残してる方がいます。

#これは〇〇という機能
#技術的に実装可能
#〇〇の関数は出力する、例：　従業者リスト、売上表

本音はね...

セキュリティエンジニアとしてデバッグ機能が残ってるかコードをチェックする際によく目にする他、

その後の実装されなかった/廃止したメソッドもコメントアウトを残してるケースも決して珍しくありません。。

ただ、幸運にもほとんどのケースでは条件が難しすぎて現実的でないので、脆弱性診断時には「情報」で済んでいます。

（ただ、こちらとしても仕事量はないに越したことはないので。。）

「せめて”."(ピリオド)でもつけてくれたらなぁ」 と感じることがございます。😶‍🌫️

今回は目を引くためにBeginnersとわざわざ書きましたが、実際は中上級者でもよくあります。。

むしろ、不勉強な中上級者ほど今までのやり方に固執して厄介ごとを増やしてるケースがあるので、

せめて賢い中上級者とこれからの初学者の方々には気を付けていただきたいです。。😮‍💨

最後に

これからますますセキュリティが幾度となく叫ばれることになると思いますが、

脆弱性と原因の大半は、(古い方から数えたほうが早い)設計・実装時のヒューマンエラーです。

不幸なことにレガシーな言語ほどそれがどうしようもないレベルまであるため、

銀行、官公庁などのレガシーシステムのコードの改修、リバースエンジニアリングなどは特に苦労を強いられるだろうな。。🤑

できれば英語で、、と言いたいところですが、、

”."(ピリオド)ひとつで問題の解決・軽微な脆弱性の対処が可能なことがあるので、

もしもに備えて頭の片隅に入れておくと役立つことがあるかもしれませんね😊

参考