ラボ

セキュリティ

HOME > Labo > WEB屋が気をつけるセキュリティ

WEB屋が気をつけるセキュリティ

登録日:2019-12-04 (12/6追記)

ニュースに出ないが、実は頻繁に起こっているWEBのトラブル

セキュリティニュースを見てますと、やれ大手有名企業のサイトが改ざんされたとか、会員情報数万件が漏えいしたとか出ています。

小規模サイトについても、WEBセキュリティに関するトラブルは実際にしょっちゅう起きていると思いますが、まぁ、どこも隠したがることなので、滅多に表に出ることはありませんね。

そこで、今回は実際に私が経験した小規模サイトのトラブル(インシデント)のケースを、エンジニアではなくWEBディレクターさん向けにご紹介しつつ、ディレクターさんレベルで気をつけておく注意点を考察したいと思います。

ちなみに小規模なWEBサイトとは、ざっくり言うと10~50ページ程のボリュームで制作費が数十万円~100万円位のサイトと言うと分かりやすいでしょうか。

(脆弱性を発見したものの、インシデントに至らなかったケースも含みます。)

あと、最初に断っておきますが、弊社のケースもあれば、相談で持ち込まれたケースもあるので、むやみに私に罪を被せないようにお願いします。

シェアウエアが原因のもの

不正ソフトの置き場所にされた

ニュース更新系のシェアウエアで起こった2004年頃のインシデントです。

状況

  1. ある日ニュースシステムがエラーになっていた
  2. サーバー内部を見るとアップロードフォルダに大量の海賊版ソフト(昔で言う割れ物)が大量にアップされていた

というもの

 

原因

プログラム自体に脆弱性があり、過去ログを表示するための引数(日付)が無害化されずにOPEN関数に流れていたため、OSコマンドインジェクションの脆弱性があった。

 

対応

ひとまず、プログラム側に入り口対策(引数の無害化)を行ったことで不正アップは止まりました。

その後、ニュースシステム自体を取り替えました。配布サイトはバージョンアップを行うこと無く閉鎖されたようです。

 

購入者の個人情報が漏えい

シェアウエアでは人気のサイトで配布されているショッピングバスケットに強制ブラウジングの脆弱性がありました。(2005年頃)

状況

  1. 個人情報を含む購入履歴の情報がCSVに蓄積されている
  2. シェアウエアなので知っている人なら該当ファイルへのURLが分かってしまう
  3. 実際そのCSVがURL直打ちでダウンロードできる
  4. Googleで漏えいしているサイトが発見できてしまう

というもの

 

原因

該当のCSVファイルはcgi-binディレクトリ内に保管されていましたが、サーバーによって実行できないファイルをリクエストした場合に、「エラーで返す」ものと「ファイルをダウンロードさせる」ものがあり、ダウンロードさせるサーバーの場合は、個人情報を含む購入履歴のCSVがモロに漏えいするというもの。

しかも、以前のGoogleはサーバーにアップロードされているファイルを見境なくインデックス・表示していたので、filetype検索で脆弱性のあるサイトが検索できてしまっていた。

パーミッションにもよります。

 

対応

弊社は実行できないファイルではエラーを返すサーバーだったので情報漏えいの被害はありませんでしたが、当時Googleの検索結果を見る限り相当な数のサイトが漏えいしていたようです。

その後、配布サイトよりバージョンアップ版が出ています。
(弊社では念の為システム自体取り替えました)

 

制作会社の独自システムによるもの

お問い合わせしたユーザー情報が丸見えの状態

リニューアル案件で、もともと設置してあったフォームメールでの脆弱性。

状況

  1. お問い合わせの内容をCSVに蓄積していた
  2. CSVファイルへの絶対パスをブラウジングすることで漏えい
  3. 前制作会社の独自(スクラッチ)のもの

 

原因

ショッピングバスケットの例と同じで、実行ファイルではないものをダウンロードさせるサーバーだった。

 

対応

プログラム自体を変更しました。

但し、スクラッチのものでしたので該当ファイルへのパスが一般には公開されていないため、ログが残っている期間ではリクエストされた形跡はありませんでした。

 

工作機械の商品情報がレイバンに!

このケースはうっかりミスで起こりうるトラブルです。

状況

  1. ある日商品情報のいくつかがレイバンに書き換えられていることに気づいた
  2. 滅多に更新しないサイトで、いつ書き換えられたかは不明
  3. 商品情報はスクラッチの更新システムだが、かなり古く管理画面へはパスワードのみでログインできるタイプ

というもの

 

原因

納品時に渡された仮パスワード(test1234)を、ユーザーが変更しないまま使用しており、完全にパスワードを当てられてしまった。
※納品時にパスワードを変更するよう言われていたが、それをすっかり忘れていた・・・らしい。

 

対応

ID/パスワードの認証と、ログインミスが複数回になるとアカウントをロックさせるようシステムを改変

 

FTPが原因と思われるもの

トップページからクリックするとフィッシングサイトへ

当ブログ「サイト改ざんを調べてみた」に詳細はありますが、最近よくある「リダイレクトハック」というもの。

状況

  1. トップページから何かしらリンクをクリックすると悪意のあるサイト(詐欺サイト)に飛ばされるようになった
  2. サイトは問い合わせフォーム以外はすべて静的ページ
  3. HTML最下部に覚えのないJavaScriptが読み込まれていた
  4. リニューアル案件でサーバー情報はクライアントから提供されたもの
  5. 改ざん時期と発病時期(1が発生した日)に4ヶ月ほどのタイムラグがあった

というもの

 

原因

ログを追いかけましたが、4ヶ月前のログが消えていたのであくまで推測となりますが、FTP情報の漏えいが濃厚でした。

 

対策

FTPアカウントの変更を行い、アップされていたJavaScriptは削除、コードも改ざん部分を削除し、現在は毎日HTMLファイルが変更されていないかをチェックするツールで監視しています。

 

CMS/OSSが原因のもの

サイトを開くとリダイレクトされる(WordPress)

状況

  1. サイトを開くと海外のサイトに問答無用にリダイレクトされる
  2. トップページの他、どのページを開こうとしてもリダイレクト
  3. CMSはワードプレス

 

原因

ワードプレスは内部のファイルにもいちいち絶対パスで記述しますが、その絶対パスの部分(一般設定の「WordPressアドレス」および「サイトアドレス」)が、「http://adjust.admarketlocation.com/bons/danf.js?k=0&adju・・・・・」というURLに変えられていた。

テスト環境から本番へ以降する際に使用した「searchreplacedb2.php」が残ったままになっており、このphpを悪用されてDBに直接書き込まれたと推測されます。

 

対応

PHPMyAdminから直接書き換えられたURLを戻し、「searchreplacedb2.php」を削除

 

不正ファイルをアップロードされた(KCFinder)

以前にコラムに書いた「KCFinderの設置の注意点」で触れた内容が実際に悪用されたケース。

状況

  1. CMSからアップロードされるフォルダに不正ファイル(eazやxml等)が大量にアップされている
  2. 削除してもしばらくするとまたアップされている
  3. CMS自体はスクラッチで、登録画面にCKEditorおよびKCFinderを使用

というもの

 

原因

WISYWIGエディタで「CKEditor」と組み合わせて使われるファイルマネージャー「KCFinder」の設置ミス。セッションを確認せず全てのアクセスをスルーさせる状態だったため、KCFinderのURLが推測され直接ファイルをポストしたと思われます。(GUIからもアップは可能)

 

対応

ひとまず、管理画面のログイン時に発行されるセッションをKCFinderからも確認するコードをconfig.phpに追記しました。

その後先方で管理システム部分にBasic認証を設定していく予定。

 

リンク先がことごく改ざん(WordPress)

状況

  1. サイト内のリンク先が詐欺サイトに飛ばされる
  2. 何度修正してもすぐ(数日以内)に書き換えられる
  3. サイト規模は20ページ前後
  4. プロバイダより危険ということで修正完了まで非表示にされる

というもの。

 

担当していた制作会社はWordPressのバージョンアップはきちんと行っていたそうですが、なぜ改ざんが止まないのかは不明とのこと。

 

原因

プラグインが怪しそうでしたが、リニューアルを考えていたこともあり、調査・復旧に費用をかけるより、WordPressを使用せずまるっと作り直してしまおうということになり、原因特定には至りませんでした。

 

対応

スクラッチのCMSで、超特急リニューアル。

 

 

ディレクターさんが注意すること

お客さんには複雑なパスワードを最初から渡す

パスワードは「推測されにくい」「使い回ししない」「桁数を長く」がポイントですが、納品時の安易な仮パスワードを変更せずず~っと使い続けているユーザーを私は沢山見てきました。

それに、もしお客さんがパスワード変更しても「使いまわしパスワード」だったらそれもまた危険です。

なので、最初から安全なパスワードにしてから渡してあげましょう。

 

フリーウエア・シェアウエアを見直す

「メールフォームは前の前の前の制作者から受け継いだプログラム」と、中を覗いてみるとフリーウエアやシェアウエアだった、ということがよくある話なんですね~。

その場合は、一度配布元のサイトでバージョンアップ版がないか、脆弱性報告がないかを確認しておきましょう。

配布サイトが閉鎖されている場合は、速やかにシステムを変更した方が無難です。

 

FTPのパスワードは引き継いだら変更する

リニューアル案件など、クライアントや前の制作会社からFTP情報を受取ると思いますが、その時点でFTPパスワードは変更する癖をつけたほうが良いかと思います。

前の制作会社のFTPクライアントには情報残ったままになってるでしょうし、制作会社を渡り歩いたサイトとなると、どこで誰が漏らすかもわかりません。

たとえ前制作会社がウィルス感染等によりFTP情報を漏えいさせてしまったとしても、自社に責任というシュートが飛んできます。(コレきついよ~!)

 

WAFを信用しすぎない

最近はリーズナブルなクラウド型WAFも増えてきたこともあり、導入するサイトも増えてきたと思います。中にはWAFを準備してくれているサーバーもありますね。

WAFもいろいろと種類があり、製品により特徴があるので適切な選択が重要となりますが、「詳しくないけど、まぁWAF入ってるから大丈夫!」と安易に信用しすぎているディレクターさんも少なくないと思います。

そこで、WordPress+サーバー会社提供のWAFのテスト環境で、管理アカウントを盗み取った体で軽く実験してみました。

詳しくは書きませんが悪意のあるソースコードを潜らせて攻撃したところ、WAFが検知したもののトップページの改ざんは防げませんでした。(ブロックされてもプロクシ一発で再び攻撃可能)

これについては、私も詳しく調べようと思っていますが、WAFといえど管理アカウントが盗まれてしまってはどうにもならなないこともあるので、やはりお客様のパスワードの状況(使いまわし、推測されやすいパスワード等)を一度見てあげても良いかと思います。

WAFについてはセキュリティリスクの軽減という認識に留めておくべきですが、「WAF入れてるからWEBセキュリティは完璧!」とつい思いがちなので気をつけましょう。(UTMも同じことが言えますね)

 

CMSなどパッケージを使用する場合のメンテ契約

WordPressをはじめJoomla!や、最近はconcrete5なども人気のようですが、オープンソースはバージョンアップ呪縛がありますので、有償メンテナンスの取り決めを行ったほうが良いです。

後からメンテナンスに費用が掛かると言っても、「え~?あなたが勧めたシステムでしょ!何都合でお金が掛かるの?」と逆に問われると、背中にびっしょり汗をかくことになります。結果、制作スタッフに無理をお願いして険悪になるのがオチです。

特に辞めたディレクターやC調営業がリスク説明せずに取ってきた案件は要注意です。

 

2023.01 追記

CMS脆弱性情報JVN iPediaという様々なシステムの脆弱性が発見されると随時公開されるサイトがあり、その中から国内でよく使われるCMSの脆弱性のみをピックアップするサイトを作りましたので、WEBディレクター、営業さん等ぜひご活用ください。

https://cms.tmp-tech.info/

 

責任分界点を取り決めておく

インシデント発生時は人間の嫌な部分が見えてしまうこともあります。

「言った言わない」は当然ながら、よくあるのが「先に言ってよ~」というヤツ。

トラブルというのは大抵「想定外」なので、経験値がなければ前もって気づくなんて至難の業ですね。

なので、企画段階でなるべくリスク想定をして、クライアントと責任分界点を決めておくことを強くお勧めします。

このディレクター、ネガティブやな!と思われてもお互いのため、転ばぬ先の杖でございます。

 

もし改ざんを発見したら

すぐに改ざんされたファイルを修正したくなりますが、まずサーバー上のファイルを全てバックアップをとっておくことをお勧めします。(タイムスタンプもそのままで)

次にメンテナンス中の画面にして、度合いにもよりますが改ざんされた部分を修正。

改ざん側のファイルと正常時のバックアップファイルを比較するのはフリーの「WinMerge」を使うと便利です。

WordPressなどCMSの場合は、本体をはじめプラグインなど範囲も広く原因を追求する作業は簡単ではありませんし、自力で特定できないこともあるかと思います。

なのでWordPressのセキュリティ対応を専門に行っている会社様を勝手に紹介しておきます。

ワードプレスドクターのブログは本当に勉強になります!

 

最後に

今年の夏に愛知県警のサイバー犯罪対策課より、私どものような制作会社に向けてセキュリティに関するアンケートが実施されました。

 

カンタンに言うと「企業に対しての情報セキュリティ啓蒙を、近い関係にあるホームページ制作会社も協力してね!」というものでした。

 

その後、県警の方とも実際にお話しましたが、愛知県だけでも企業よりホームページのセキュリティについて様々な相談が寄せられているそうです。(とくにワードプレスに関するものが多いとも)

 

 

セキュリティと言えば、高度な知識と技術をもった一部の人の世界と思っているWEBディレクターさんも少なくないと思いますが、通常業務の中でちょっと気をつけるだけでセキュリティ・リスクを減らすこともできると思います。

また、IT系では常識的に行っている作業(例えばパスワードを書いたtxtを暗号化したZIPにして渡す等)のやり方をお客様にも教えるだけでも、情報社会の役に立つのではないでしょうか。

 

この記事はお役に立ちましたか?

役に立たなかった  役にたった

ページトップ