3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

IPA 安全なウェブサイトの作り方の所感

Last updated at Posted at 2020-10-05

#背景
初めて投稿します。
私はITの知識ゼロからエンジニアとして学んでいる、新卒1年目の初心者になります。

研修を通して、WEBシステムについて調べたり、
簡単なログイン機能のあるWEBサイトを作る経験をさせていただきました。
現在は、業務をを通して少しずつ知見を広げている最中になります。

今回は、今まで特に意識していなかった、「セキュリティ」についての学習のため、
IPAの「安全なウェブサイトの作り方」という
資料を読んだので所感を綴らせていただきたいと思います。

#安全ウェブサイトの作り方とは

IPAが届出を受けた脆弱性関連情報を基に、
届出件数の多かった脆弱性や攻撃による影響度が大きい
脆弱性を取り上げ、ウェブサイト開発者や運営者が
適切なセキュリティを考慮したウェブサイトを
作成するための資料です。

IPA「安全なWebサイトの作り方」

#読んでみて感じたこと
研修で実装したウェブサイトでは、PHPでMySQLに接続し、
ユーザ名、パスワードやメールアドレス等を操作していました。

私が実装した際にセキュリティ面で考慮したことは
 ・HTTPSで通信できるようにする
 ・パスワードをハッシュ化してDBに置く
程度で、とりあえず「機能要件を満たす」ということを重視していました。

というのも、クライアントへ操作を求める際(アカウント作成や、ログイン時など)
攻撃される可能性があるということを理解していませんでした。

安全性の低いウェブアプリケーションを実装すると、
個人情報など外部に漏らしてはいけない情報が
インターネット上に晒されている状態になってしまいます。
非常に危険なことだと今は認識しています。

#特に重要だと感じた部分
ここ必要だったな、と感じた部分や、なるほどと思った部分を
自分の学習も兼ねてまとめます。

###SQLインジェクション
SQLインジェクションは、パスワードなど入力時に悪意のあるユーザが、
データベースへ不正な命令文を送信する攻撃です。

危険性としてはこのようなことが挙げられます。
 ・DBの情報を見られてしまう
 ・DBの情報の改ざん 
 ・ストアドプロシージャ等でOSの操作

ユーザの入力情報をそのままSQLに連結してしまうと、
不正なSQLを実行してしまう可能性があるため非常に危険です。

なので、SQL文に入力情報を使う場合は
情報が入る場所(プレースホルダ)を設定し、割り当て(バインド)する必要があります。
また、特別な意味を持つ記号文字を文字列として認識させる処理(エスケープ)をします。

PHPでMySQLを接続するのにPDOを使ったのですが、意味もあまり理解していませんでした。
しかし、SQLインジェクションによる不正操作を防ぐ役割もあるということが理解できました。

###クロスサイトスクリプティング
クロスサイトスクリプティングは、入力時にスクリプト等を埋め込まれて、
不正な操作をされることです。

危険性としては下記のようなものになります。
 ・本来とは異なる表示、スクリプトの実行
 ・スクリプトによってCookieを取得されたり、改ざん

クライアントの入力した情報を出力する場合などには
クロスサイトスクリプティングの注意が必要です。

自分の作ったウェブサイトでは、ログイン後のホーム画面に
入力したユーザ名を表示させるという処理をしていました。       
しかし、HTMLテキストのエスケープ処理をしていなかったため、
スクリプトを表示されてしまうという脆弱性が確認できました。

対策として、ウェブページに出力する要素にエスケープ処理を施し、
不正な表示をさせないようにさせる必要があったなと感じています。

###クロスサイトリクエストフォージェリ
クロスサイトリクエストフォージェリは、ログインしたクライアントが、
ウェブサイトに意図しないリクエストをさせられることになります。

危険性としては、これらが挙げられます。
 ・ログイン後に利用可能サービスの悪用
 ・ログイン後に編集可能な情報の改ざん

cookieやセッションでログイン状態を保持したり、ベーシック認証でアクセス許可する
場合などには注意が必要です。
罠サイトなどでこれらの情報が抜き取られ、攻撃が行われてしまう可能性があります。

対策としては、セッションにワンタイムトークンなどを利用することが挙げられます。
クライアントにhiddenパラメータとして、トークンをPOSTメソッドで送信させ、
セッションと一致するか確認することで、不正なリクエストを判断できます。
またログイン中でも、重要な処理を実行する直前で再度パスワードを求めることや、
リファラーのリンク元を確認などで、不正か判断する方法もあります。

実習では、セッションを利用してログイン状態を判断していました。しかし、
そこでは、ユーザのメールアドレス(ユーザの一意な情報)を使用していました。
これでは、罠サイトにアクセスしてしまった場合、非常に危険だったと反省しています。

加えて、新規アカウント作成時に、メールアドレスが使用済みの場合バリデーションを
表示していたので、使われているかが分かってしまう仕様でした。
もしセッションIDがメールアドレスだと分かっていたら、
成りすましてログインされてしまうという可能性もにも気づくことができました。

#最後に
今まで意識していなかった「セキュリティ」について、
どのような視点から考えればよいのか、という基本的な視点を理解できました。
また、ある脅威に対して、根本的対策だけでなく、保険的な対策をすることで
より安全で安心して利用できるウェブサイトになると分かりました。
今後開発に関わる際には、どんな攻撃を受ける可能性があるか、
考えられる脆弱性はないかという視点も持ちながら
実装できるように学習していきたいと思います。

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?