webアプリを作ること自体はそこまで難易度が高くありません。
しかしセキュリティについて意識せず、穴があるプログラムを作ってしまうことで、利用者の情報を漏洩してしまったり、利用者に害のあるプログラムをばらまいてしまったりしてしまう可能性があることは知っておくべきです。
セキュリティについて気を付けるべきこと
まずはどのような攻撃を受ける可能性があるかを知っておきましょう。
IPA（独立行政法人情報処理推進機構）のチェックリストに寄ると気を付けるべき攻撃は11種類でした。
1.SQLインジェクション
MySQLなどのデータベースを利用するようなサイトで、入力欄にSQL文を入れて悪意のあるSQL文を実行させる攻撃となります。
・被害
顧客情報の流出等。
・対策
利用者が入力した文字列をそのままSQLに利用するようなプログラムを書かない。入力された値をエスケープして利用するかプレースホルダを利用する。
2.OSコマンド・インジェクション
webアプリなどが動いているサーバーに対し不正なOSコマンドを実行させようとする攻撃。
・被害
情報漏洩やマルウェア感染等。
・対策
コマンドラインを実行する場合のパラメーターにユーザーが入力した値を使わない。入力された値をエスケープして利用する。
3.ディレクトリ・トラバーサル
不正な入力を行い本来公開されていないファイルやフォルダを不正に閲覧しようとする攻撃。
・被害
情報漏洩やシステムの乗っ取り・改ざん等。
・対策
ファイルの読み込みなどでパスを指定する際にユーザーが入力した値を利用しない。
4.セッション管理の不備
おそらくセッションハイジャックなどのことかと思いますが、別のユーザーなどでログインするなりすましなどを行う攻撃になります。
・被害
悪意を持ったユーザーに他人になりすまされる＝ログイン後に個人情報ページがあれば漏洩も有り。
・対策
セッションIDに推測しやすい短い文字列などを使わない。HTTP時にはCookieにsecure属性を付与する。
5.クロスサイト・スクリプティング
ユーザーが入力した文字列を表示させる掲示板のようなサービスにおいて、悪意のあるスクリプトを入力しサイト上で実行させることを狙う。
・被害
Cookie情報の漏洩やwebサイトの改ざん等。
・対策
ユーザーが入力した文字列をそのままweb上に表示させない、エスケープ処理を適切に行う。
6.CSRF（クロスサイト・リクエスト・フォージェリ）
SNSなどにログインしている状態で攻撃サイトにアクセスするとログインしたユーザーとして不正な操作を行えるようになってしまう攻撃。
・被害
ログインしているサイトでの不正な操作（書き込みやパスワード変更など）。
・対策
リクエストの送信元が正しいことであることを示す情報を付加する。
7.HTTPヘッダ・インジェクション
HTTPヘッダに悪意のあるコードを挿入し、意図しない操作を行う攻撃。
・被害
なりすまし等。
・対策
ユーザーが入力した値に直接リダイレクトするなどヘッダの出力にユーザーが入力した値がそのまま出るようなプログラムを書かない。
8.メールヘッダ・インジェクション
お問い合わせフォームのあるサイトで、メール内容を改ざんし迷惑メールを送信させるなどの攻撃。
・被害
迷惑メール送信に加担してしまう。
・対策
言語に用意されているメール送信関数を利用する。
9.クリックジャッキング
iframeを利用し、意図しないリンクやボタンをクリックさせる攻撃。
・被害
悪意のあるサイトへのリンクをクリックさせられたり、特定サイトで意図しない操作を誘導される。
・対策
X-FRAME-OPTIONSを設定する。
10.バッファオーバーフロー
コンピューターに大量のデータを送り付け誤作動を誘発させる攻撃。
・被害
コンピューターの乗っ取り、攻撃への踏み台化など。
・対策
脆弱性の修正されたバージョンのライブラリの利用。
11.アクセス制御や認可制御の欠落
他人が知り得る情報でのみでログインできてしまうなどの欠陥。
・被害
他人のメールアドレスや電話番号がわかればその情報のみでその人物としてログインできてしまう等。
・対策
ログイン認証にはパスワードの入力も必須とする。
セキュリティについて意識すべきこと
まず上記の攻撃方法においてその多くが「ユーザーが入力した値をそのまま利用する」ことに起因しています。
ユーザーが入力した値は絶対に安全ではない、必ずエスケープするなどしてからデータ登録したりといった利用をするという意識が重要です。
大体どの言語であっても文字列をエスケープする関数が用意されているので、エスケープする際にはそれらの関数を利用するのが楽です。
ただし推奨されていない関数も残っていたりするので、問題が無いか検索して確認しておくと良いです。
実はフレームワークが解決してくれるものも多い
絶対とは言えないので過信は禁物ですが、フレームワークに置いてSQLインジェクションはマッパーにより対策されていたり、XSSにおいてはビューに渡す値は必ずHTMLエスケープが挟まれていたりと対策がなされています。
もしお使いのフレームワークに対策がなされていない場合はご注意ください。意外と対策されていない部分もあるフレームワークもあります。
フレームワークでカバーしきれないかなと思うところでは
- OSコマンド・インジェクション
- ディレクトリ・トラバーサル
あたりですかね、これもユーザーが入力した値をそのままパスの指定に利用しないということを意識しておけば防げます。
逆にバッファオーバーフローに関してはweb系の言語では発生率は低いかなと思うのと、対策としても脆弱性対策されたライブラリを利用するくらいしかできないので常に脆弱性関連の情報を収集しておくことくらいです。
最後のアクセス制御や認可制御の欠落が言葉が曖昧でわかりづらいですが、結構重要なポイントかなと思います。
本来その人が触れてはいけない他人の情報にURLを直接いじったり推測することで触れてしまったりするといった設計のミスもあり得ますし、色々な視点から脆弱な作りになっていないか気にかけていくしかないですね。
セキュリティチェックツール
完璧とは言えませんがwebサイトのセキュリティに問題が無いかをチェックしてくれるツールもあります。
代表的なものは「OWASP ZAP」自分のPCにダウンロードしてインストール後に使うタイプのツールです。ダウンロードサイトが英語なので最初面食らうかもですがdownloadのページに行くだけなので大丈夫です。
自分のサイトのURLを入れると脆弱性が無いかをチェックしてくれるので使い方も難しいことはないです。
絶対にやってはいけないこととして、他人が運営するサイトのURLを入力することです。悪意はなくても攻撃をしかけたとして逮捕されたなんて事例もあるくらいですからね。
あとはツールも利用しつつやはり最後は作った本人による手動チェックも忘れずにしておきましょう。
まとめ
webアプリって簡単に作れることは作れるのですが、ここまでセキュリティを考慮すると結構大変です。
外部に一般公開するようなwebアプリを作る場合には、新しくセキュリティ対策が施されているフレームワークを利用して開発するのが一番無難だと思います。
大事なのは「ユーザーが入力した値をそのまま利用しないこと」