ドラゴンクエストの「ふっかつのじゅもん」で味わう認証の奥深さ（ITmedia NEWS） - Yahoo!ニュース
この記事は認証セキュリティ情報サイト「せぐなべ」に掲載された「架空世界 認証セキュリティセミナー 第24回『ふっかつのじゅもんが ちがいます【ドラゴンクエスト】」（2018年6月28日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。当時未発売だった製品やサービスの記述などは、本記事掲載時の状況に合わせて編集しています。 これが ふっかつのじゅもん だ（画像） ……それでは講義を始める。今回が定期講義としては最終講義である。最後まで心して読むように。 前回は「ルパン三世」を題材に「人脈認証」などについて解説した。筆者としてはおバカな「脳力認証」ネタの方も好きなのだが……。「ルパン三世PART5」も、気になる諸君は見てみると良いだろう。 さて、最終回の題材は「ドラゴンクエスト」である。不朽の名作といわれるRPGシリーズであるが、どこに認証が隠れているのだろうか。早速見て
セキュリティエンジニアを将来の夢にしているのですが現在高2なのですが現在大学選びに悩んでいて、セキュリティエンジニアは自分が... - Yahoo!知恵袋
徳丸さんにご推薦を頂いて光栄です。立命館大学の上原です。 私からも補足を。 セキュリティの分野で今、最先端で活躍しておられる方の中には、少なからず「大学でも専門学校でもセキュリティのことを学ばなかった」方がおられます。中には、そもそも高校を出てすぐこの世界に入ってこられ、全くの独学で大変高い技術を身につけられた方もいらっしゃいます。なので、「セキュリティエンジニアは技術さえあれば学歴は関係ない」と言われるのだと思います。 ですが、こういう先達の方々はご自分で大変努力されていること、また、セキュリティの問題がそれほど複雑でなかった時代から、複雑化した現代までの経過をずっとリアルタイムで追ってこられたという、言わば「産まれた時代が良かった」という点は見逃せないと思います。これからセキュリティエンジニアを目指す方がその境地追いつくのは大変です。そのためには、基礎からきっちりと体系立てて学ばれるこ
OSSEC ではじめるセキュリティログ監視 - クックパッド開発者ブログ
インフラストラクチャー部の星 (@kani_b) です。 Heartbleed, ShellShock, XSA-108 (a.k.a. EC2 インスタンス再起動祭), POODLE など、今年は話題となるような脆弱性が各地を襲う一年でした。 脆弱性への対応に加え、いわゆるセキュリティ対策に日頃頭を悩ませている方も多いのではないかと思います。 一言にセキュリティ対策と言っても、実際やるべきことは多岐にわたります。今回はそのうちの一つとして、OSSEC という IDS (侵入検知システム) を使ったセキュリティログ監視についてご紹介します。 OSSEC とは OSSEC は、いわゆるホスト型の IDS (HIDS) です。以下のような機能を持っています。 ログ解析、監視 ファイルの変更監視 rootkit の検知 それらをトリガにしたプログラムの自動実行 (Active Response)
[iOS]アプリに強制アップデート機能を導入すべき理由と、簡単に実装する方法 - Qiita
強制アップデートとは？ 多くのアプリを利用されている方でしたら、何度か下記の画像のようなアラートでアップデートを促されたことがあるかと思います。このアラートは閉じるボタンが存在せず、「AppStoreへ」のボタンしか存在しないため、ユーザーにはアプリを操作するためにはアプリをアップデートする以外に選択肢がありません。この記事では、この様なアラートをアプリ起動時に表示する機能を強制アップデート機能と呼び、なぜそれが必要なのかと、たった3行でこの機能を導入できるライブラリについて記述します。 なぜ強制アップデートが必要なのか？ iOS7以降、自動アップデート機能は追加されたもののもちろん全てのユーザーがそれを利用しているわけではありません。中には、リリースから半年以上経過しても初期バージョンを利用し続けるユーザーの方もいます。では、この様に古いバージョンを利用しているユーザーも多くいる状態で、
![[iOS]アプリに強制アップデート機能を導入すべき理由と、簡単に実装する方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5159b91764b2498b61048fc3120b30061ff3b732/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCaU9TJTVEJUUzJTgyJUEyJUUzJTgzJTk3JUUzJTgzJUFBJUUzJTgxJUFCJUU1JUJDJUI3JUU1JTg4JUI2JUUzJTgyJUEyJUUzJTgzJTgzJUUzJTgzJTk3JUUzJTgzJTg3JUUzJTgzJUJDJUUzJTgzJTg4JUU2JUE5JTlGJUU4JTgzJUJEJUUzJTgyJTkyJUU1JUIwJThFJUU1JTg1JUE1JUUzJTgxJTk5JUUzJTgxJUI5JUUzJTgxJThEJUU3JTkwJTg2JUU3JTk0JUIxJUUzJTgxJUE4JUUzJTgwJTgxJUU3JUIwJUExJUU1JThEJTk4JUUzJTgxJUFCJUU1JUFFJTlGJUU4JUEzJTg1JUUzJTgxJTk5JUUzJTgyJThCJUU2JTk2JUI5JUU2JUIzJTk1JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz05ZGQxYTlhNTZhOWVjOGMyNGM1OTgxZmJmMzg2OTgxZQ%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwa2F6dTA2MjAmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTBkZDdjNTU5ZjhlMDRmMGQwMGQ5ZWJhOWM1YzJhOGQ2%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D29f37959ababd0713cb24c2d9df93c60)
COOKPADの「伏せ字にせず入力」ボタンは素晴らしい
@tokuhiromから教えてもらったのですが、COOKPADのスマートフォン向けWebサイトのログインページには、パスワードを「伏せ字にせず入力」するボタンがついているのですね。 さっそく見てみましょう。まずはログイン画面です。パスワード欄の下側に、「伏せ字にせず入力」ボタンが見えます。 「元に戻す」ボタンを押すと、伏せ字に戻ります。 僕はこれを知って興奮しました。なぜなら、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」には以下のように書いたからです（P337～P338）。 パスワード入力欄のマスク表示は、現在の常識的なガイドラインですが、実は筆者自身は疑問を持っています。パスワード入力欄をマスク表示にすると、記号や大文字・小文字交じりの安全なパスワードを入力しにくくなるので、利用者は簡単な（危険な）パスワードを好むようになり、かえって安全性を阻害するリスクの方が大きいのでは
SET NAMESは禁止
(Last Updated On: 2018年8月13日)MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。（PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります）この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。 Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。 PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が
Moony::log - PHPだけでBasic認証
何かの拍子で使わないとも限らないのでメモ代わりに書いておく。ざっくりと流れだけ。 <?php if (!authenticate($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW'])) { header('WWW-Authenticate: Basic realm="title here"'); header('HTTP/1.1 401 Unauthorized'); echo 'Authentication failure.'; exit; } function authenticate($user, $password) { return ($user === VALID_USER && md5($password) === VALID_PASSWORD); } ?> authenticate関数の部分でデータベースアクセスするようにす
携帯業界の認証事情 Part2 - y-kawazの日記
先日の日記で携帯の認証に関しての考察をして、とりあえずキャリア毎のIP制限を行っていれば端末IDやユーザID認証を信用していいのでは無いか？と書いたのだが、更に調べた結果どうも怪しい実態が見えてきたので危険度と合わせて再度纏めてみようと思う。 とりあえず指摘があったので前回のテストに加えて以下を試してみました。 NO uidに指定した値 実際に送信されてくる値 8 %30%31%32%33%34%35%36%37%38%39%61%62*1 1234567890ab うわ弱っ、駄目じゃん。見事にuidの詐称が成功してしまった…。 DoCoMoのユーザIDの信頼性が地に落ちた瞬間です。 2007-03-01追記）DoCoMoスゲー！昨日は確かに上記の方法で詐称できたのに、今日はもう既に対策されとるし(^^; 今、同じことを試すと以下のメッセージが出るのみでした。 IPサイトの記述に誤りがある
フォームの2重送信はセキュリティ問題か?
(Last Updated On: 2006年11月16日)備考：前のエントリのコメントに対してこのエントリを作成しました。 セキュリティ対策の3大要素の一つとしてデータの整合性（Integrity）があります。3要素は私が勝手に決めたことではなくISO規格でも決まっています。 個別のアプリでの解釈の問題になりますが、データの整合性に重複送信が含まれない、と考えるのであればコメントされている通り「発想が変」と言う考え方になるかもしれません。重要なデータでなければ（例えばブログへのコメントなど）安全性とは無関係といってもあまり差し支えないです。しかし、注文や送金などのデータでは致命的です。 # 認証システムが無いサイト（必要ないサイト） # に「認証システムが無い」からといって「セキュリ # ティ問題だ」と騒ぐ必要がないのと同じでデータ整 # 合性が必要ないサイトではセキュリティ問題になり
今夜分かるSQLインジェクション対策 ― ＠IT
【関連記事】 本内容についてのアップデート記事を公開しています。あわせてご確認ください（編集部） Security&Trustウォッチ（60） 今夜こそわかる安全なSQLの呼び出し方 ～ 高木浩光氏に聞いてみた http://www.atmarkit.co.jp/fsecurity/column/ueno/60.html Webアプリケーションに対する攻撃手法の1つであるSQLインジェクションの存在は、かなり広く知られるようになった。しかし、その対策はまだ本当に理解されていないように思える。フォームから渡された値の特殊文字をエスケープしたり、PHPのmagic_quotes_gpcといった自動エスケープ機能をオンにするだけで対策したつもりになっていないだろうか。 基本はもちろん、セカンドオーダーSQLインジェクションやマルチバイト文字を利用したSQLインジェクションの攻撃パターンや、その対
PHPで安全なセッション管理を実現する方法
_ 残り容量が数十Mバイトになっていた PCがなんかくそ遅いなーと思ってふと空きディスク容量をみたら、残り数十Mバイトまで減っていた。Folder Size for Windowsで各ディレクトリ単位のディスク使用量をながめてみたところ、 Thunderbirdでimapでアクセスしているアカウントのデータフォルダに、なぜか1GバイトオーバーのINBOXファイルがあった。なにこれ？ 削除したけど別に動作には支障はなし。 puttyのlogが無限に追記されたよ……。数Gバイト。 昔ダウンロードしたCD/DVD-ROMのisoイメージファイルが、そこかしこに消されず残ってたよ。10Gバイトオーバー。 あと、細かいテンポラリディレクトリの中身とか消したら、30Gバイトくらい空いた。そこまでやって久しぶりにデフラグを起動したら、表示が真っ赤（ほとんど全部断片化されている）だったので、最適化実行中。
星野君のWebアプリほのぼの改造計画 連載インデックス - ＠IT -
セミナー申し込みフォームがスパムの踏み台？ 星野君のWebアプリほのぼの改造計画（1） 念願のWeb担当に異動した星野君。最初の仕事はセミナーのWeb申し込みフォームを3日で作ることだった（2005/10/15） ・セミナー申し込みフォームを3日で作れ！ ・Webサーバはどこだろう？ ・Web申し込みフォームなんて簡単ですよ ・スパムの踏み台は想定外！？ 誰でもWeb管理画面に入れる気前のいい会社 星野君のWebアプリほのぼの改造計画（2） 星野君に与えられた次なる指令は……仕事がなかった。しかたなく「Web管理ツール」を調べてみると……（2005/11/19） ・仕事がない！ ・サーバ上にある「admin」フォルダの謎 ・「admin」フォルダを封鎖せよ ・SQLインジェクション、発見！ ・助けて！ まこと先輩 ・Webアプリ改造計画発動－SQLインジェクション編 Webアプリ、入力チェ
超初級CGIクラックガイド ■tokix.net
この世で一番分かりやすいクラックはCGIクラックだと思います。単純な理由です。この世に存在するほぼ全てのクラックは「裏技」です。例えばFC版ドラクエ4でコイン買う時に極端に多い枚数を指定すると値段が安くなるって裏技があったの覚えてますか？あの原理は単純ですよね。 「買い物でいくら払うか」という変数が0-16777215の領域までしか用意されていない。だから20000000Gの買い物ならば値段は20000000-16777215Gになる。 「（プログラムの）原理が分かる」ということは「裏技の原理が分かる」ということです。そして「クラックは裏技だ」というのは「デバッグ(？)されてたら通用しないよ」という意味でもあります。 しかし普通のWinユーザーはUNIXの動作原理は勿論Winの動作原理･IEの動作原理等々を知っている訳ではありません。ただ高級言語（我々人間に理解しやすい言語）で記述されたC
公開中のHTMLファイルがごっそり消失！？
公開中のHTMLファイルがごっそり消失！？：星野君のWebアプリほのぼの改造計画（7）（2/3 ページ） うっかりログインしてしまうと、犯行の痕跡が消える！？ 安直に元に戻すのも気が引けたのだが、ただ単にデータが消えてしまっただけなのか、何か不正なアクセスを受けて故意に消されてしまったのかがいまの段階では分からないので、「原状復帰優先！」といわれても特に反論はできなかった。本来であればネットワークから切り離して時間をかけて解析をしたいところだ。 そんなやりとりを隣の席で聞いていた赤坂さんが、星野君に話し掛けてきた。 赤坂さん 「なんかあったの？ファイルが消えたとか聞こえたけど」 星野君 「Webサーバ内のファイルがいつの間にかごっそり消えちゃったんですよ。特にファイルが消えるような作業はしてないんですけどねー」 赤坂さん 「なんか面白そう♪それ、私も手伝っていい？」 星野君 「あ、もちろん
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
魔女狩りかPerl狩りか : 404 Blog Not Found
2006年01月18日00:45 カテゴリLightweight LanguagesOpen Source 魔女狩りかPerl狩りか それは聞き捨てならない。 高木浩光＠自宅の日記 - 続・「サニタイズ言うなキャンペーン」とは 結論からズバリ言えば、Perlのせいだ。そもそも、セキュリティを電脳言語の層で確保しようとするのは、その言語の汎用性が高ければ高いほど不可能になる。汎用性の中には、「あえて危険なことを承知で行う」ということも含まれているのだから。 その点において、最も危険な言語は圧倒的にCということになる。実際CERTの勧告でも圧倒的に多いのがCで書かれたソフトウェアであるし、そもそもPerlを始め多くの電脳言語の実装そのものがCで書かれているのだから。 20世紀の時代、CGIプログラミングといえばPerlだった。Perlは、open 関数のように、手軽な書き方を用意しているのがク
Webアプリ、入力チェックで万事OK？
Webアプリ、入力チェックで万事OK？：星野君のWebアプリほのぼの改造計画（3）（2/5 ページ） ほかのWebアプリケーションもささっと検査してよ 平野部長からお呼びが掛かった。 平野部長 「Webのプロジェクトを本格始動する前に、セキュリティをちゃんとした方がいいんじゃないかってことになってね。ほら、またSQLインジェクションとかあると困るじゃない」 星野君 「そうですねぇ」 平野部長 「セキュリティ詳しいみたいだからさ、星野君にほかのやつも大丈夫か見てもらうことになったからよろしく」 星野君 「ええっ。僕がですか？？えっと、そんなに詳しくないんですけど……」 平野部長 「まあまあ、謙遜しなくてもいいよ。頼んだからね」 星野君は、またしても平野部長に一方的に押し切られ、検査対象となっているWebアプリケーションの資料を渡された。それは、現在会社のWeb上で稼働している「お問い合わせ」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gihyo.jp が Webサイトの VMコントロールパネルを乗っ取られた？ - Yukarin'Note
http://cgi36.plala.or.jp/tera5/v/security/webap_sec2/chap01.html
第8回WebSig会議 ディレクター・製作者が知っておくべきセキュリティ | 作者プロフィール