たかがFOLIOという1サービスの開発に、23歳が2年もの時間を捧げてしまった話
ついにここまで来た。 1年と10ヶ月。 僕と代表の甲斐が出会ってから、ちょうどそのくらいだ。 出会ってから3ヶ月で共にFOLIOという会社を創業し、当時23歳の僕が、もう25歳になった。 自分でいうのもなんだけど、若者の2年は非常に貴重な時間だ。 その2年を、僕はたかが1つのサービスの開発につぎ込んだ。 リーンスタートアップだのアジャイル開発だのMVPだの、最低限のクオリティのプロダクトをだしてから実際にお客様の声をききながら改善していくことが「正」とされる近年の中で、はたから見れば愚かなスタートアップであることは間違いない。 正直僕だってキツかった。 今まで僕は、様々なハッカソンやアプリコンテストにでたり、プライベートでもとりあえず思いつきのアイデアはほぼすべてつくってきた。（参考：プロフィール＞ポートフォリオ） おかげで大学生～社会人にかけては、同じ2年間で数えると30を超える賞をもら
IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第2章 アクセス制御
複数のWebアプリケーションがユーザ認証の機能を外部に一元化することによって、ユーザがパスワードを覚える負担を低減することができる。また、Webアプリケーションのオーナは、パーソナル情報の管理の負担とリスクを外部に転嫁することができる。 外部のユーザ認証サービスと連係動作するしくみ パスワードを用いたユーザ認証機能として、Webアプリケーションから利用可能な外部サービスが、2005年頃から提供されるようになってきた。 参考資料： 『アイデンティティ管理技術解説』 ユーザによるアクセス要求を遮断できるコードを開発して、そこから外部のユーザ認証サービスとアクセス認可判定の処理を順に呼び出すようにする。この要求を遮断できるコードは、PEP（Policy Enforcement Point）の役割を果たす。 ユーザ認証の結果をPEPに伝達するしくみとしては、「HTTPリダイレクト」の機能が応用され
DOM ベース XSS 対策チートシート - OWASP
クロスサイトスクリプティング (XSS) は、一般に次の 3 種類に分類されます。 反射型、格納型、および DOM ベースの XSS です。反射型 XSS と格納型 XSS については、XSS 対策チートシートで詳しく取り上げています。このチートシートでは、ドキュメントオブジェクトモデル (DOM) ベースの XSS について説明します。このチートシートは、XSS 対策チートシートの延長であり、その内容の理解を前提としています。 DOM ベースの XSS を理解するには、DOM ベースの XSS と反射型および格納型 XSS との基本的な違いを知る必要があります。最も大きな違いは、攻撃がどこでアプリケーションに挿入されるかです。反射型 XSS と格納型 XSS がサーバー側でのインジェクションの問題であるのに対し、DOM ベースの XSS はクライアント (ブラウザー) 側でのインジェクシ
クロスサイトスクリプティング (XSS) 対策チートシート - OWASP
この資料では、適切に出力のエスケープ / エンコードを使用した XSS 対策について、シンプルかつポジティブなモデルを紹介します。極めて多くの XSS 攻撃ベクトルがありますが、いくつかのシンプルなルールに従うことで、この重大な攻撃を完全に防ぐことができます。この資料では、XSS の技術的な影響、ビジネスへの影響は扱いません。XSS を使用すれば、攻撃者は、被害者がブラウザーを使用して実行可能なあらゆる行為を行うことができるとだけ、ここでは述べておきます。 反射型 XSS と格納型 XSS の両方ともに、サーバー側で適切な検証とエスケープを実行することで対応できます。DOM ベース XSS には、DOM ベース XSS 対策チートシートで説明する特殊なルールのサブセットにより対応できます。 XSS 関連の攻撃ベクトルについてのチートシートは、XSS フィルター回避チートシートを参照してくだ
情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
XMLHttpRequestを使ったCSRF(補足編) - 葉っぱ日記
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記を書いていて思ったけど、いまいちXHRを使ったCSRF(というかクロスオリジン通信)について理解されていないような感じだったので、ちょっと書いておきます。とりあえず日本語のリソース的には、HTTP access control | MDN が詳しくて、それを読めばだいたい事足りるんで、あとはCSRFに関連しそうな話題だけ。 Q. そもそも「クロスオリジン」って何？ スキーム、ホスト、ポートの3つの組み合わせが一致している場合を同一オリジン(same-origin)、いずれか一つでもことなる場合をクロスオリジン(cross-origin)と言います。つまり、XHRでドメインを超えて通信している場合は典型的なクロスオリジン通信となります。 Q. え？ XMLHttpReuest って他のドメインにリクエストを発行できないんじゃ い
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
独自ヘッダをチェックするだけのステートレスなCSRF対策は有効なのか？ — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
「WebAPIのステートレスなCSRF対策」という2011-12-04の記事がありました。 ここで説明されているCSRF対策は、 GET、HEAD、OPTIONSメソッドのHTTPリクエストはCSRF保護の対象外 HTTPリクエストにX-Requested-Byヘッダがなければエラーにする という非常にシンプルなものです。 そして、この対策の原理として以下の説明がありました。 form, iframe, imageなどからのリクエストではHTTPリクエストに独自のヘッダを付与することができません。独自のヘッダをつけるにはXMLHttpRequestを使うしかないわけです。そしてXMLHttpRequestを使う場合にはSame Origin Policyが適用されるため攻撃者のドメインからHTTPリクエストがくることはない、ということのようです。 ここで、 XMLHttpRequestを使
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IPA-安全なウェブサイトの作り方2021年改訂第7版.pdf
ウェブ健康診断仕様