HTMLはわかるけど、サーバーサイドはお遊びでphpを触ったぐらいだったので、会員制でデータをためこむサイト作りに初めて挑戦した。 今回重視したのは、「いかに個人情報をお漏らししないようにして、万が一漏らしても被害を少なくするか」ということ。 世の中、有償サービスでもパスワードを平文で保存してるサービスが意外と多いらしいので、流出した時のリスクを少しでも減らせる対策として書きます。 今回のシステム構成サーバー:ロケットネットのキャンペーンにでレンタルサーバ年1000円ポッキリプラン クライアント側の処理:HTML+CSS+jQuery(とプラグインもろもろ) サーバ側の処理:PHP Webサーバー:Apache データベース:MySQL 個人情報こわい!個人情報ビビる。漏洩とかまじ困るし怒られるしこわい。 俺も巻き込まれたところでは、サミータウンがメールアドレスとパスワードセットでお漏らし
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest(ヘッダおよび、POSTの場合はボディを含む)を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse(ヘッダおよび、HTML)を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
(2011/03/04 14:00 追記)id:shin1x1さんのはてブコメントに基づきheader関数の挙動について修正しました。ご指摘ありがとうございました。 徳丸浩さん(id:ockeghem)が書かれたセキュリティ本『体系的に学ぶ 安全なWebアプリケーションの作り方』が3/1に発売されました。この本はPHPのサンプルコードがふんだんに提示されているセキュリティの解説書で、セキュリティの理解を深めたいWeb技術者全員にお勧めしたい本です。 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 作者: 徳丸浩出版社/メーカー: SBクリエイティブ発売日: 2011/03/01メディア: 単行本購入: 119人 クリック: 4,283回この商品を含むブログ (146件) を見る 僕はこの本のレビュアーとして参加させて頂きましたが、他のレビュアーの方々が
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
_ XSSI そういえば XSSI という攻撃があることを知った。 web サイトのオーナーができる種類の攻撃で、 cookie つきな JSON でなんかやってるサイトだと、 その JSON を全く関係ない web サイトを <script> で 読み込むことによってデータを盗める、と。 しくみとしては JSONP 的なのを逆に攻撃に使えるっていう まぁ当たり前の話ではあるけど、なるほどなと。 対策としては )]}' みたいな文字で JSON のレスポンスを開始して、 自分の JS 内ではこれを読み飛ばしてやればいいらしい。 他には POST しか受けないようにしちゃうとか、 XSRF 同様予想不能な ID とかを URL に含めるとかもいいらしい。 http://code.google.com/p/browsersec/wiki/Part2#Navigation_and_content
ニコニコPodder iPhone/iPod/iPad対応ニコニコ動画簡単インポートツール aggregateGithubCommits GitHubレポジトリでのコミット数をAuthor/期間別に集計します probeCOCOATek 新型コロナ接触確認アプリCOCOAが配布するTEKを表示・集計 結論から書き出すと、結局のところ楽天銀行アプリはUDIDを通常(初期)ログインとクイックログインそれぞれのタイミングでサーバー送出をしていた。この事実からは楽天CERTの説明には不信がある。 さてどうしてくれようというのが現時点な訳だが、まずはどういう仕様で楽天銀行アプリが動作しているのか明らかにしてみよう。楽天CERT担当者からは「即座に悪用できるものではない」との見解ももらっているしまたそもそもリバースエンジニアリングしている訳でもなく公共のインターネットを飛び交っているデータプロトコルに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く