WEBアプリケーションにおける攻撃と対策
WEBアプリの抱えるセキュリティ脅威
WEBアプリケーションは基本的に世界中に公開されている状態であり、 提供するサービスを受ける一般ユーザーのみではなく、悪意を持った第三者も当然利用が可能である。
そのため、まずはWEBアプリケーションがどのような攻撃を受ける可能性があるのか調べることにする。
また、WEBアプリは大別すると２種類あります。
- WEB API
- 要求に応じて特別な加工のないデータのみのやりとり（参照/登録）が可能。
- WEBサイト
- 要求に応じて 専用アプリケーションで表示をすることで視覚的に柔軟なアプローチが可能なデータ を返却する。
二つのアプリケーションは基本的にhttpプロトコルを利用する。 一部GoogleコンテンツはQuickを利用？
WEB APIは無加工のデータをあらかじめAPI側で定義した形式に則ってやりとりすることで、 直接データの参照や登録や変更、削除が可能です。 （一般的にはGETメソッド、POSTメソッド、PUTメソッド、DELETEメソッドを利用する）
上記に対しWEBサイトは基本的にデータ取得（GETメソッド）のみが可能で、 取得した特殊加工（HTML+CSS）されたデータを専用アプリケーション（ブラウザ）で表示することで APIのみの場合より視覚的なアプローチが可能。
もちろん取得するデータも所詮HTTPプロトコルを用いてやりとりされるデータでしかないので、 ブラウザを使わなくてもデータの中を参照することは可能です。
ただ、データは専用アプリで表示する前提で加工されている状態なので情報をぱっと見で視覚的に理解することは困難だと思います。
WEBコンテンツ内で定義していれば、アプリ内からデータの登録や変更なども可能。
今更説明しようとしても全部冗長になりがち。意味わかんなかったり間違ってたらごめんなさい。
WEBアプリ全般で言える攻撃を受けた場合の影響内容
WEBアプリケーションは世界中に公開されている性質上 誰からでも攻撃を受け付ける状態 であると言えます。
攻撃された結果何につながるかというと、 WEBサイトの製作者が意図しない情報にサイト全体が書き換えられたり、 さらに別のWEBサイトへ攻撃する際の踏み台として利用されてしまったりします。
せっかく開発したコンテンツは信用を失い、最悪の場合は罰を受けなければいけなくなってしまう可能性があります。
なので、しっかりと対策をしましょうねということでこれから本題。
サーバーが受ける可能性のある攻撃の種類
- ポートスキャン
- バッファオーバーフロー
- パスワードクラック
- セッションハイジャック
- DNSサーバー攻撃
- DDoS
- ウィルス
- なりすまし
- SYN Flood
なんか色々あるみたいですん。ここまで書き始めて15分。
全部説明するとキリがないのでポートスキャンというもっともあるあるな攻撃手法を説明することでまず攻撃はこういう感じです、 という感覚を掴んでいただけると。
ポートスキャン攻撃
ポートスキャンは、攻撃対象のサイトに対してどのポートが開いているかを手当たり次第攻撃する手法です。 WEBサイトは80番ポートが利用されるのが一般的ですが、それ以外のポートを利用（有名なのだと8080とか）している場合もあります。
また、WEBアプリケーションはサービスを提供する上でメンテナンスが絶対に必要なので、 メンテナンスするためにWEBアプリケーションの中（サーバー）に入るためのポートも開いてたりします。 （SSHだと22、とかとかだけど普通は変える）
３WAYハンドシェイクというTCP接続を確立するためのネットワークにおけるお約束事があります。
3wayの名の通りSYN->SYN/ACK->ACK というやりとりを行いますが、 SYN/ACKが帰ってきた時点で開いていると判断する場合もあるみたいです。 （開いてない場合はRST/ACKを返すため）
攻撃者は手当たり次第に開いているポートを調べて、開いているポートを見つけたらポート番号から 一般的にどのようなサービスで利用されるポートかあたりをつけて次の攻撃にうつります。
とにかく中国からの攻撃が多い。とにかく多い。
WEBアプリケーションに絞った攻撃
WEBアプリケーションの脆弱性に関する対策は、普通に診断師資格があるのでそれを参考に設計していくのがベターかもしれない。
Pentester Skillmap Project JP - OWASP
ただ、小難しい。
脆弱性をリリース前からチェックする
専門資格があるものに対して知識もない中立ち向かおうとする労力は賞賛に値する。 ただ、どうやっても勝てないし、だから専門の資格があるわけで。
そこで、こう言った攻撃を想定したテストツールを使ったります。
脆弱性診断・脆弱性検査ツール５選 | ソフトウェアテスト・第三者検証ならウェブレッジ
リリース後のDDoS対策など
まあ結局アプリ側でどんなに対策をしようが防ぎきれないのが攻撃です。 毎日攻撃手法が確立されている昨今、大抵の大手アプリにはアプリの前段にファイアーウォールを配置します。
大規模サービスではデータセンターでラックを借りてネットワーク機器から設置するパターンが基本でした。一昔前までは。 ただ、最近はクラウドネイティブとかわけわからん言葉が生まれるくらいクラウドが前提。なのでルーターとかスイッチとか設置できない。
最近はネットワーク機器メーカーもソフトウェアルータを出し始めているので、そう言ったものを導入するのもいいかもしれません。 ネットワークにはメーカー品を入れるのが吉です。輻輳制御とかファイアーウォールとか、結局動作の安定性が全然違うので。
ただ、流行りのk8s(Kubernetes)やDockerに入れようとすると大手のネットワークメーカは非対応なんじゃないかな？（記憶が古い？） F5さんとかロードバランサーとか作っているような強い会社さんはもしかしたらあるかもしれない。
で、そういう場合はVyattaを使う。そこで攻撃をフィルターしてしまうという方法もあります。
が、運用保守がアホみたいに大変になる。
自前で行うネットワークセキュリティ
Routerで受けた攻撃と思われる攻撃を外部のサービス（確かAKAMAI？違うかも）にそのまま投げたりすることで 流れてくる異常量なトラフィックを制御するわけなんだけど、思いつく手法は以下。
Netflowというネットワーク機器のトラフィックのアナライズ設定があるんですが、こいつをONにし、 アナライズ用データを外部サービスに投げることで攻撃を受けているか検知する。
外部サービスというのが例えばAkamaiだったりするわけなんだけど（Akamaiさん違ったらごめんなさい）、 それ以外にも自前で構築することも可能。
それがElastic Stack。
Netflowというのは少し特殊なデータを送出してて、解析するには専用のFlowCollectorというものが必要だったりする。 これがアホみたいに高い。100万以上が当たり前だったように記憶している。
これをLogstashというElastic Stackのパーサーで受け取って、Elasticsearchというデータベースで蓄積する。 Elastic StackはKibanaという可視化ツールも持っており、これによってグラフ化することが可能。 また、WatcherというこれまたElastic StackのKibana用だったかな？のプラグインを使用して、 機械学習によっていきちによる異常検知を行なってもいい。
また、パーサーを自前で（例えばPythonとかNode.js）作ってデータを受け、 データを登録するときに前回データと差分を比較するようにして検知してもいいと思う。
そんなことしなくても前段にWAF置けばいいじゃん
そう、上記みたいな面倒なことは前世代の話だったのである。 WAFをご存知だろうか。（私は知らなかった）
提供するサービスのネットワークで考えた前段（入り口）にWAFを置くのが当たり前らしい。
提供者は色々あって、セキュリティ専門企業だとSymantecが出しているみたい。 AzureだとAzureの提供サービスにWAFがありました。
Azure Application Gateway の Web アプリケーション ファイアウォールの概要 | Microsoft Docs
他にもSucutum？とか色々あるみたいだけど、要はWEBアプリケーションが受ける攻撃に特化した装置で、 こいつを置くことでクロスサイトフォージェリとか色々な対策を勝手にしてくれて、おかしなアクセスをする奴に対しては こいつがブロックをしてくれるという便利ツール。
値段は結構する。Azureが一番安かったから、AzureのApplication GateWayを利用してサービス提供をしている人はこれがベストかもしれない。
と思ってたらNginxには謎のコンポーネントが存在していた。。
(構築例はこちらを参考にするといいかも) nginx向けのWebアプリケーションファイアウォールを試す | さくらのナレッジ
NAXSIは Nginx Anti Xss and Sql Injection の略らしい。
確かにWAFの主要機能の一部ですね。
ここによるとサポートしている機能は以下っぽい。
- XSS, SQL injection, CSRF, File include からの防衛
- 既知の攻撃に対するシグネチャー以外の防衛
- GET/POST リクエストのチェック
- HTTP ヘッダとクッキーのチェック
- 危険な記号類、SQL キーワードの禁止
- 単純な設定
- ホワイトリストアプローチ
- 学習モード
2に関してはよくわからなかったんですが、SBさんのブログでは
脆弱性のある良く知られた パターンの99% を含む単純なルールが用意されており、例えば、 URIの一部として <,|, drop などは含まれてはならない などです。
って書いてありました。
結局アンチパターンを設定したりして設定がキモになりそうですね。 エンジニア的には楽しいけど、運用考えたり色々考えると不安は残るよなあと思う。 知識量次第だしね..
セキュリティはやりすぎると首が絞まる
ユーザビリティが下がったり、開発するときに面倒ごとが増えたり。 クラウド型のWAFを使うのが結局無難で楽なのかなあなんて思ったりしましたというお話でした。
