1月26日(火)2コマ目

今日、やったこと

クロスサイトスクリプティング

今日のホワイトボード

クロスサイトスクリプティング

JavaScrtipはCookie中のセッションIDにアクセスできるか？

Cookie中のセッションIDはHttpOnly属性がONになっているため、JavaScriptからはアクセスできない。

図　JavaScriptはCookie中のセッションIDにアクセスできない


クロスサイトスクリプティング対策

ユーザー入力データのような安全が保障されていないデータをそのまま出力していることが問題。何が書き込まれているかわからないデータはそのままブラウザに出力せず、HTMLタグを無効化するサニタイジングを行うこと。

図　クロスサイトスクリプティング対策


コメント

新しいコメントは書き込めません。

このブログの人気の投稿

1月6日(水)1コマ目

イメージ
今日、やったこと フィルター 今日のホワイトボード 2020年末からのつづきです。「安全なWebアプリケーション構築」というタイトルで、認証を行うアプリケーションを構築してきました。 作成途中のWebアプリケーションをリハビリがてら以下のように改造してもらいました。 図　改造内容 いちおう、ソースコードです。 IndexSrvクラス(サーブレット) doPost()で認証OKなら [改造前]/WEB-INF/userinfo.jspへフォワード [改造後]SecondPageSrvへリダイレクト に改造。これで認証成功ならクライアントはSecondPageSrvへリダイレクトさせられる。 リダイレクト=>クライアントはリダイレクト先を再度リクエストする。 SecondPageSrvクラス(サーブレット) 追加。 doGet()で/WEB-INF/userinfo.jspへフォワード。 クライアントが直接アクセス可能？不可能？ 主にJSPやHTMLファイルですが、どこに置くか(WebContentフォルダかWEB-INFフォルダか） で、ブラウザからアクセスできる、できないのコントロールができます。 図　クライアントが直接アクセス可能？不可能？ WEB-INF以下に置いたJSP(HTMLも)はブラウザから直接アクセスできません。 WEB-INF以下のJSPの表示はサーブレット内でフォワードすることになります。 未ログインならログインページに飛ばしたい ブラウザのアドレスに2ページ目のURL(http://xxx/SecondPageSrv)を入力すると、ログインページを経由せずに2ページ目にアクセスできます。 このような未ログインの状態でログインページ以外をリクエストした場合、ログインページに飛ばしたいです。 これを実現するにはサーブレット実行前に実行されるフィルターを使って、ログイン済みかチェッ...
続きを読む

11月25日(水)1コマ目

イメージ
今日の予習 スレッドに関する内容を扱います。 スレッドのライフライクル スレッドは新規作成から終了まで下図のように状態が変わります。 新規作成 Threadクラスのインスタンス生成された時であり、まだこの時点ではシステム資源（CPU)は割り当てされていません。 実行可能状態 start()メソッドが実行されると新規作成状態から実行可能状態になります。この状態でもまだ処理は行われません。 スレッドには優先順位があり、実行可能状態のスレッドは実行可能キューで順番待ちをしています。順番が回ってくると実行中となります。 実行中 スレッドにシステム資源が割り当てられ、スレッドの処理が実行されている状態です。 「実行中」の遷移先は次の３つに分かれます。 ○より優先順位の高いスレッドが発生したとき 「実行可能状態」へ ○wait()、sleep()メソッドが実行された、入出力等で処理の遅延が発生した、排他制御でロックされたとき 「待ち状態」へ ○処理が完了したとき 「終了」へ 終了 run()メソッド内の処理が終わり、スレッドが消滅した状態や、run()メソッド実行中に例外が発生して途中で終了した状態です。 今日、やったこと バッファオーバーフロー確認テストの解説 今日のホワイトボード 確認テストの解説 先週のページ に解説を載せておきました。こちらもご参考ください。 メモリ プログラム実行のさい、メモリは下表の３つのエリアを使います。 コードエリア 実行する命令が置かれる。 メモリ番地の低位アドレスからエリアが確保される ヒープエリア 大きめのデータ用のエリア。C言語でmalloc()で確保する...
続きを読む

10月14日(水)1コマ目

イメージ
きょう、やったこと バッファオーバーフロー 今日のホワイトボード コンピュータのメモリ とりあえず下図の３つのエリアをおさえてください。 図　コンピュータのメモリ バッファオーバーフロー コンピュータシステムの重大インシデントの要因ナンバーワン（と思われる）がバッファオーバーフロー。C言語特有の「メモリ操作が簡単にできる」＋「メモリ保護がない」から簡単に発生する。いやらしいのは発生するパターンが限定されるケースが多いこと。(再現性が高くない） サンプルプログラムについて （一応）認証を行うプログラム。 コマンドライン引数にて、認証に使うパスワードを指定して実行。 なお、認証OKなパスワードは「SamplePassword」。 しかしながら、パスワード「aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa」（aを30個)を指定すると、認証OKとなる。 原因はバッファオーバーフローによるメモリ破壊。実際にメモリがどうなっているかをデバッガを使って確認してみる。 バッファオバーフローはstrcpy()で発生している デバッガで、strcpy()直後にブレークポイントを設定。 ブレークポイントで停止後、２つの変数(auth_flag、password_buffer)の中身を見てみると、以下のようになっていた。 図　strcpy()後のメモリの様子 おかしな動きをした理由はいくつかの要素が複合的に重なっているためです。 要素１　strcpy() strcpy()は 　 コピー先のサイズに関係なく、コピー元の先頭から'\0'までをコピーする ため、password_bufferのエリアを超えて、auth_flagのエリアまで上書きをしてしまった。 要素2　check()の戻り値 変数auth_flagの値を返しているが、auth_flagは 初期値0で宣言 strcmp()で”SamplePassword”と一致したら、1を代入 の2か所で代入を行っている。 strcpy()でバッファオーバーフローして上書きされても正しい値を代入することがない。 要素3　c言語のif() カッコ内が 　0なら条件不成立 　0以外なら条件成立 です。c言語にはtrue、falseがないため、このような仕様になっています。 よって、check()関数の戻り値が0以外なら認証...
続きを読む