2012年2月29日水曜日

[お勉強]ぴよぴよセキュアWebアプリ制作(6)

ここからは当分脆弱性の解説で

◇既知の脆弱性
開発されたWEBアプリではなく、
OSやWEBサーバ(Apache/IIS)、DB、FTP、SSH、SMTP、DNSなどのサービス
の脆弱性をつく攻撃。

被害:
サービス妨害、サーバののっとり、踏み台、DBからの情報流出など。

基本的にパッチ適応やバージョンアップによって対応できる。

◇製品の誤設定
OS、サーバ、アプリケーションサーバの設定ミスを利用した攻撃。
構築時の設定ミスだけではなく、設定変更時のミスにも注意。
ー>バージョンアップしたときに設定ファイルがデフォルトで上書きされることもある!

被害:
データファイルを見つけられて、情報がもれる
CGIが実行されずにファイルの内容が表示されてしまう
(適切な実行権限が与えられていなかったり、拡張子が.php.txt、.php.hogeなどに
なっていたりするとCGIとして実行されずにファイルの中身がみえてしまう)

◇パスワード攻撃
<方法>
  • 総当たり攻撃(全数件数)
  • 辞書攻撃
ともにWEBアプリだけでなくSSHなどOSやパスワード認証を行っている
サービスすべてに行われる一般的な攻撃手法

☆リバース攻撃
総当たり攻撃の中には、1つのIDに対するパスワードの総当たりではなくて
特定のパスワードをもつユーザのIDを総当たりで調べるリバース攻撃もある。
例)
  「AAAAA」というパスワードをもつユーザをすべて調べる

またログイン失敗の場合にアカウントをロックする仕様の場合、
任意のアカウントをロックされる可能性もある。

<対策>
○総当たり攻撃
英数字6文字以上になると実質的に総当たりは不可能
ユーザ登録する場合、英数字6文字、数字10文字以上の制限をつけて
☆☆長さの制限はつけない☆☆

○辞書攻撃
あらかじめ用意した辞書をつかったパスワード攻撃。
パスワードが英数字6文字以上でも辞書にはいった単語を使っていた場合、
辞書攻撃は有効な攻撃手段となる。
攻撃に必要な時間は辞書攻撃よりも小さい。


[お勉強]ぴよぴよセキュアWebアプリ制作(5)

続きました。
さてさて今日はもーちょっとがんばるかー。

◇攻撃手法あれこれ
WEBアプリケーションに対する攻撃手法 14項目
ざっくりと名前と概念を。

既知の脆弱性への攻撃

サードパーティのパッケージの設定ミスをついてくる

総当たりとか辞書攻撃とか、パスワード解析以外にも
故意的なアカウントのロックなどもある

バッファオーバーフロー
大量のデータをおくってバッファをあふれさせる

強制ブラウズ
URLを直接指定するなどで制限つきのページを閲覧する

情報の意図せざる流出
システムが返すエラーメッセージから本来公開する必要のない情報が漏洩する

不十分なエラー処理
エラーの処理において、攻撃者に有益な情報が表示される
たとえばソフトのバージョンとかディレクトリ名とか

システムのバックドアやデバックモードの残存
バックドア、デバッグモードを探しだして不正にそれを使う

ステルスコマンド操作
(1)SQLインジェクション
不正なSQLを実行させる
普通のSQLインジェクションとブラインドSQLインジェクションがある

(2)OSコマンドインジェクション
不正なOSコマンドを実行させる

HTTPヘッダインジェクション
HTTPレスポンスを偽造し、サイトのユーザを攻撃する

セッションハイジャック/リプレイ(推測/奪取)
他人のセッションを奪うまたは強制的に再現する

セッションフィクセーション(強制)
攻撃者が指定したセッションIDをWEBアプリケーションに使わせる

クロスサイトリクエストフォージェリー
正規のユーザを誘導し、強制的に特定の処理を実行させる


次からは個別にみていくよ!

[お勉強]ぴよぴよセキュアWebアプリ制作(4)

関東雪降るウルウドシ。
white leap day!!
さむーい!

おふとんにくるまりながら今日もまとめていきますよ。
Let's Study!

◇脆弱性がつくりこまれるタイミング
  • 設計段階
  • プログラミング段階

○設計段階での注意点

設計段階でつくりこまれた脆弱性が
プログラミング段階でみつかると
修正コストが跳ね上がる。
当たり前だけど運用で見つかってしまうと
さらに多くのコストがかかる。

ので

設計の地点でセキュリティをがっつり考慮すること。

めんどくさいからって
「まずはリリース!後からまとめて直した方が効率的!」
とか考えないこと!!

○プログラミング段階での注意点
プログラミング段階でつくられる脆弱性は
プログラミングのミスや処理の抜けが原因でおきるバグ。
  • 入力値チェック
  • 出力時チェック

で防ぐことができる。

  • 入力値チェック

 入力した値が許可されたものかをチェックし内部の処理を正常に動作さるためのもの
 根本的対策にはならないが、攻撃パターンを減らすという意味で保険的対策となる
  • 出力時の処理

 出力データを正しいフォーマットにするためのもの
 これを怠ると、XSSやSQLインジェクションの原因となる。

[お勉強]ぴよぴよセキュアWebアプリ制作(3)

さて続き続き!

今日は勉強会してきた。眠いけどがんばるよ!!

◇セキュアWEBサイトにするために
☆情報、昨日の提供先は「可能な限り、狭く、限定する」

情報を限り、使える人を限り、操作を限り、できるだけなにもさせない。

そういえばサーバ構築の基本は
「できるだけなにもいれない。可能な限り不要なユーザはつくらない。
ユーザ権限はできるだけあたえない。
便利だからってなんでもいれたりとかしない!!!」
って最初に教わったけど、おなじようなものですね。

◇根本的対策と保険的対策
セキュリティホールに対する対策には


  • 根本的対策
  • 保険的対策


がある。

根本的対策は
そもそも被害がおきないようにするためのもの
☆☆重要
対策としては「技術の仕様にそった正しい実装をする、しかない

☆☆根本的対策の例
HTML本文に入力値を出力する場合、かならずエスケープ表記にしてサニタイジングを行う=XSSの根本的対策
これはHTMLの仕様としてかならずそう書くように定められているから行うもの。
(参考)
@IT: クロスサイトスクリプティング対策の基本
http://www.atmarkit.co.jp/fsecurity/special/34xss/xss01.html

☆☆重要
HTMLタグのエスケープ表記
<&lt;
>&gt;
"&quot;
&&amp;
'&#039;

※HTMLのエスケープ表記は
&なんちゃら;で表記する

※覚え方
   左が大きい:>
   「&gt;」の「gt」は「greater than」
右が大きい:<
「&lt;」の「lt」は「less than」
A less/greater than B
    A > B  = A greater than B
    A < B A less than B
   左のほうが大きい場合(>)場合、gt
   左の方がちいさい(<)場合、lt 
 
シングルクオートの 039は語呂合わせしかなさそうなので
0を「ム」とよんでムサクに覚えるシングルクオートぐらいでおぼえておくよ!


保険的対策は
特定のパターンに対してBracklist的に対策をとるもの。

根本的対策が不十分だった場合や、正しく機能しなかった場合、
あたらしい攻撃手法ができた場合などに役に立つ。
ひとつの根本的対策を行うだけではなく、
可能な保険的対策を多重に行っておくことで
攻撃をされにくく、攻撃された際の被害を小さくできる。



2012年2月27日月曜日

[お勉強]ぴよぴよセキュアWebアプリ制作(2)

さて続き続き。
ちょい長いので記事をわけわけ。

なお、記事の分け方に一定のルールはありません


You can do it!! 元気出していきましょー!

セキュアなWebアプリのためのそのイーチ!

◇バグとセキュリティホール
○バグとは?
ー期待する動作と実際のプログラムの動作がことなること
ー人的ミスによって発生する!! 
=> だから完全に消すのは無理!!でも減らせ。限界まで減らせ!!

○セキュリティホールとは?
システムの
・機密性
・完全性
・可用性
に影響を及ぼすバグ
=> つまりバグの一種。いってしまえばヤバいバグ。
==>> バグへらせばセキュリティホールへらせるじゃん。減らせ。限界まで減らせ!!

セキュリティホール=機密性、完全性、可用性に影響を及ぼす
バグなのでバグを減らすことで
結果的にセキュリティホールも減る。

☆☆重要
機密性、完全性、可用性
は重要なので覚えておくこと(キ、カ、カでおぼえてね♪)

◇入力値は信頼するんじゃない
新人:
この内容正しいフォームからおくられてきたからOKですよね?
とおしちゃいます♪

リーダー:
まて。

すーべーてーの入力値は操作可能!
よって信用するべからず!


今までうまれたすべての入力値とこれからうまれるすべての入力値を
チェックしたい。この手で(キリッ


この手でかどうかはさておき。
すべてのユーザ入力値は一切信用してはいけません


 HTMLで入力制限かけてようが攻撃者はそんな壁を超えて悪意のあるコードを
送ってきます。


入力制限を回避する方法例は(回避を回避する方法にアラズ)

・ローカルHTMLの書き換え
ブラウザにうつしたWEBページをローカルPCに保存し、
HTMLを編集、再度ブラウザに表示して好きな値を送ることができる

・ブラウザの拡張機能によるHTMLの書き換え
ローカルではなくてブラウザの拡張機能によりHTMLを書き換えて
すきな値を送る方法
IE Developer Toolbar、Web Developerなどが使える

・ローカルプロキシ
Burp Proxy
ローカルでうごくプロキシサーバ
ブラウザ -> HTTPリクエスト -> Burp Proxy (HTTPリクエストを書き換え) -> サーバ
というふうに
Httpリクエスト/レスポンス、HTTPヘッダなどを書き換えて使うことができちゃう。
比較的簡単に扱えるので悪用されると怖い

・HTTPで直接通信する
telnetとか、ねぇ。httpリクエスト直におくれちゃうので
いくらでもすきな内容おくれちゃう


◇入力値は信頼するんじゃない2
新人:
まじですか。
じゃフォームとHTTPリクエストだけみとけば大丈夫ですよね?
チェックしときまーす。

リーダー:
まった。まだある!
あらゆるすべての、つまりアプリケーションが利用するすべての入力データが対象だ。


入力はフォームだけではない。
やつらはどこにでもいる。そうわれわれの足下にも。。。

足下かどうかはさておき。

・メール
 メールリンクやメールを読み込んで出力するアプリなどは
 メールが入力手段になる場合がある。

・データベース
 DBに格納されたデータをアプリケーションが利用する場合、
 格納データが安全ものであるかどうかチェックが必要。
 格納する際に十分なチェックがされていなかったり、
 DBのデータが壊れていたりする場合があるのでDBデータ=安全
 であるとは言い切れない。

・ファイル
 データファイルやログファイルなど安全性の検証が十分ではない場合がある。
 例えば攻撃コードが含まれたログを解析したときに、コードが動き
 攻撃につながることもある。

>>続きます





[お勉強]ぴよぴよセキュアWebアプリ制作

プログラマは一年生。ちいさなことから一歩ずつ。
ということでセキュアなWebアプリ制作についてのお勉強ですよ。

学習内容はブログに書いてもいいよーって先生から
いわれたのでまとめる!!!

◇セキュリティ対策の重要性
セキュリティインシデントがおきると?

・復旧コスト
・社会的信用の低下
・株価の下落
・ユーザの流出
・ユーザへの賠償
・Pマークの取り消し/JIPDECに取り消し事業者名がさらされちゃう!!

などの被害が発生する => 対策しないと!!!

◇セキュリティインシデントの動向

従来:
OSやサービス(WEB、MAIL、DNSなど)を狙ってきたので
パッチ適応でなんとかできてた

現在:
Webアプリ、Webアプリの構成要素(DBとかDBとかDBの中身とか!)
が対象になってきたので別の対策が必要!!!


=>どうしてかわってきたの?

  •  WEBアプリは入り口(80番ポート)に制限がない
  •  攻撃が容易、成功率が高い、攻撃の検出が難しい
  •  被害が大きい(ので攻撃したがる)
  ☆WEBアプリは80番ボートの制限がないので攻撃が容易で成功しやすい!



=> どんな対策をすればいいの?

  • そもそもセキュアに作れよ(セキュアなアプリケーションの開発)
  • いまあるものはいっこずつ直すか〜(個別アプリケーションの改修)
  • 全体みなおさないとあかんね...(サイト全体の設計を改修)

◇WEBアプリケーションへの攻撃
(1)FW/IDSの穴
FWは万能じゃない!やつらふさいでないポートまではみてくれない。
頼りがいのあるあいつにも無力なときもあるんだぜ?Baby
☆80/443は開いているのが前提なのでFW/IDSはWEBアプリの攻撃には意味がない

(2)HTTPSの穴
HTTPSは万能じゃない。やつら暗号化が得意なだけだ。
通信内容そのものを監視してくれるわけじゃない。
あたまが良さそうに見えてぬけてるところもあるんだぜ?Baby。
☆HTTPSは通信経路を暗号化するだけで入力値による攻撃は防げない

わかったかい。お嬢ちゃん。
別の対策が必要なんだぜ?
うっかり攻撃されちゃったらこんなことまでされちゃうんだぜ。

・OSへの攻撃
・DBの不正使用 ->情報漏洩
   ・DBへの不正アクセス -> DB破壊

気をつけるんだぜ。お嬢ちゃん。
crackerは皆オオカミさ

。。。。。なんだこのノリ

◇脆弱制の統計

○IPA届出状況による脆弱制の統計

  1. XSS (43%)
  2. SQLインジェクション
  3. ファイルの誤った公開
  4. DNS情報の設定不備
  5. パス名パラメータの未チェック(ディレクトリトラバーサル)


○MBSDセキュリティ検査実績

  1. XSS(69%)
  2. 不十分なエラー処理
  3. クロスサイトリクエストフォージェリー(CSRF)
  4. 不要なファイル公開
  5. パラメータ操作に対する脆弱制

このあたりはざくっとながして
IPAは一般ユーザからの報告をもとにしているので
ユーザがみつけやすい脆弱制が上位にあがりやすい、
MBSDはMBSDが調査しているので内部的な内容が多い、って感じ。
個々の脆弱性の解説はあとからなので
今はこういう脆弱制があることぐらいを頭に入れておく程度に。
各脆弱性の種類は後ほど。

>>続くよ!














2012年2月24日金曜日

ADKハッカソンに参加してみた後日談

で、ADKってなに?
ってぐらいの機械音痴なものでざっくりまとめ。

◇ADK/Accessory Deveropment Kit

Androidとつながる周辺機器の開発キット。
Androidとつなげたときの振る舞いが普通のUSBデバイスと逆に
AndroidがUSBホストにつながってるような感じになるので
周辺機器から電源をもらったりできる。

イケテる!:あつかうのが楽。
イケテない!:どこまで使えるのかいまんとこわからない。

ってぐらいのお話をしてもらったと思うのだけど。

まちがっていたらごめんなさい。
ほんとごめんなさい。

(参考)
@mhidaka さんの How to ADK

ブリリアントサービスのADKとArduinoの使いかた

ADKハッカソンに参加しました

はじめてのまともな記事。はじめてのまともなテーマ。
いってくるよ。ハッカソン!!


2/5、itogさんの主催するADKハッカソンにデザイナーとして
参加してきました。
(pigmalさんのブログでロゴつかってもらってる!わーい!)

きっかけはぬる舗のたこ焼きパーティ。
「ADKハッカソンでちょいアイコンつくれる人がいたらいいな」
「やりますー!」

そんな流れでお邪魔することになったADKハッカソン。
第一印象はまるで学校の技術室。
コードがたくさんあったり、なににつかうかわからない(すいません)機材があったり、ロボットが動いてたり。
参加している皆様も真剣!

チームは5チーム、17時までという短い時間の中午前中はアイデアソン、午後からもくもく
と制作開始。
のんびり構えていた私も急に増えだす画像のオーダーにばたばた対応。
このスピード感がハッカソン!たのしいねー☆
みんなぎりぎりまでがんばるがんばる!

プレゼン資料はpigmalさんの公式ブログにてご紹介

気になる投票結果は(じゃかじゃん(効果音

  • 1位チームようてん
  • 2位チームマッププラス
  • 3位チームたこルカ
となりました。

ぼっちにもかかわらずちゃんとうごくものをしかもかっこいいもの
仕上げたようてんさんに拍手!!

チームマッププラスのマップアプリはぐりぐりうごいてて気持ちがよかった!
チームたこルカさんは完成してないのが残念><。。

その後の懇親会では技術トークも繰り広げられ、わからないなりにたくさんのお話が
聞けてふだん触れられないようなものに触れられてとても楽しくて有意義な一日でした。

お誘いいただいたitogさん。
参加者の皆様。

心から感謝いたします。ありがとうございました!
今後ともよろしくお願いします

















2012年2月8日水曜日

むかしからつづけていること

文章を書くのは割と好きです。
あたりまえみたいに読むのも好きです。

意味のわからないコピーや
どうでもいい洒落をふわふわ考えるのも好きです。

気の向くままにショートショートなんかを書きあらすのも大好きです。

ときどき思い出したように眺めみると
そこにいる彼らはそれぞれとても誰かに似ていたりして。


ふとそのときのことを思い出したりするのです。













2012年2月1日水曜日

昨日がおわって今日がきて今日がおわって明日になって明日がおわって
あさってになって、気がついたら体までいれかわっている生きている不思議。


時間が経てば物理的に別人だよね。
じゃあ私って何?設計図?

そーかもしれないし、そーじゃないかもしれないし。
でもそういうことは別にどうでもいい。

明日のパンとか今日着る服とか目の前の仕事とか。
となりのだれかの笑顔とか。

だいじなことはそーゆーことかもしれないね。

えりーさんのほんのり日々と
えりーさんのあたまんなか。