セキュリティブック「セキュリティ 7つの習慣・20の事例」 – MOTEX Inc.
ITの進歩により便利になる一方、その影に潜むリスクは 企業だけでなくあなたのすぐそばまで迫っています。 でも、ウイルス感染や情報漏えいなんて、自分は大丈夫。 セキュリティは面倒くさいし、どう学べばいいかわからない。 そう思っていませんか？ どんなに高い投資をしてツールをいれても、 会社の大切な資産を守るためには、社員一人ひとりの意識が大切です。 また、あなた個人の身を守るためにも、あなた自身の意識が必要です。 本書は、まず身につけておくべき「セキュリティ 7つの習慣」、 また身近に起こる様々なリスクをQ&A形式の「20の事例」にまとめました。 セキュリティの基礎を学びたい方や社会人としての教養を身に付けたい方、 会社でのセキュリティ研修やマナー研修などにご活用ください。 本書・資料が皆様の“セキュリティリテラシー向上” のお役に立てれば幸いです。 2017年2月 エムオーテックス株式会社
ネット・セキュリティとサンタさん - Qiita
ミクシィのイノベーション・センターで社内新規事業インキュベーション、そして人事部で新卒採用支援をやっているもりもとです。こんにちは。 この投稿はmixiグループ Advent Calendar 2015の23日目の記事です。 Advent Calendarはクリスマスにちなんだ企画です。せっかくですから、ミッションスクールに12年通った私としては、今日はクリスマス寄せで書きます。 コンピュータ・ネットワークといえば、いまやセキュリティの知識と対策は切り離せません。 大勢のみなさんのプライバシーをお預かりするSNS mixiを開発・運営しているミクシィでは、これは一層もちろんのこと。「本物そっくりのmixi.jpを擬似攻撃してやっつけちゃえ!」というWeb脆弱性攻略体験イベントScrap Challengeも、毎年シーズンを重ね、すでにかれこれ11回開催しているぐらいです。 もちろん来年度も
Heartbleedバグのコードを解説 - Qiita
今回バグってたのはheartbeat extension という機能の実装。 RFCはこちら https://tools.ietf.org/html/rfc6520 Heartbleedバグに対する修正コミット http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=96db9023b881d7cd9f379b0c154650d6c108e9a3 バグ解説 4. Heartbeat Request and Response Messages The Heartbeat protocol messages consist of their type and an arbitrary payload and padding. struct { HeartbeatMessageType type; uint16 payload_length
間違いだらけのSQL識別子エスケープ
これから3回連載の予定で、SQL識別子のエスケープの問題について記事を書きます。SQL識別子のエスケープについてはあまり解説記事などがなく、エンジニア間で十分な合意がないような気がしますので、これらの記事が議論のきっかけになれば幸いです。 3回の予定は以下のとおりです。 間違いだらけのSQL識別子エスケープ(本稿) SQL識別子エスケープのバグの事例 SQL識別子は結局どうすればよいか ということで、まずはSQL識別子のエスケープの失敗例について説明します。この失敗例はあくまで説明のために作ったもので、実際のものではありません。また、想定が「ありえない」と思われるかもしれませんが、意図的なものですのでご容赦いただければと思います。また、「間違いだらけの」というタイトルは、今回の題材が間違いだらけという意味であり、巷のSQL呼び出しがそうであるという意味ではありません。本稿に登場する人物と団
社内勉強会でSOP (Same Origin Policy) の話をしました｜TechRacho by BPS株式会社
baba 高校時代から趣味でプログラミングを始め，そのままずっとコードを書いています。2010年SFC卒業，在学中にBPS入社。ゲームなどの趣味プログラミング，Webシステム，スマホアプリ，超縦書エンジン(C++/Chromium)，Webフロントエンド(TypeScript/React)などを主にやってきました。最近は自社製品(超シリーズ，くんシリーズ)の開発に関わるお仕事が中心です。管理業務もしますが，ゆとりプログラマーなので気楽にPCに向かっているのが好きです。 情報処理技術者試験(16区分 + 情報処理安全確保支援士試験)，技術士(情報工学部門)，中小企業診断士、Ruby Programmer Gold，AWS Certified Solutions Architect - Professional，日商簿記2級，漢検準1級。情報処理技術者試験 試験委員(2021-)。 babaの
安全なPHPアプリケーションの作り方2013
PHPカンファレンス2013における徳丸のプレゼン資料です。後から、参考文献などを加筆しました。Read less
いまさら聞けないパスワードの取り扱い方
そうだったのか！ よくわかる process.nextTick() node.jsのイベントループを理解するshigeki_ohtsu
パスワードの定期的変更について徳丸さんに聞いてみた(1)
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、お伺いしたいことですが、パスワードを定期的に変更すべしという根拠には、どのようなものがあるのでしょうか? 徳丸: 大きく分けて2つの理由が挙げられていると思います。一つは、パスワードを定期的に変更すると、パスワードを破って侵入する攻撃の予防になるというもの、すなわち事前の予防策です。もう一つは、パスワードが漏洩した際に、被害を軽減できるというもので、事後の緩和策ということですね。 高橋: もう少し詳しくお願いします。 徳丸: まず、「事前」の方ですが、オンライン攻撃とオフライン攻撃があります。 高橋: オンライン攻撃とはどのようなものでしょうか? 徳丸: オンライン攻撃は、ネット経由でパスワード
Cassandra、Redis、memcachedに潜む脆弱性
Cassandra、Redis、memcachedに潜む脆弱性：NoSQLを使うなら知っておきたいセキュリティの話（3）（1/2 ページ） MongoDB以外のNoSQLに潜む脆弱性 前々回、前回の2回に分けて、NoSQLのうち「MongoDB」を用いたWebアプリケーションの脆弱性と対策について紹介してきました。 ここからは、MongoDB以外のNoSQLを使うアプリケーションのセキュリティについて簡単に説明します。取り上げるのは、Cassandra、Redis、memcachedの3つのNoSQLデータベースです。まずはCassandraについて見ていきます。 Cassandraを使うアプリケーションのセキュリティ Cassandraは列指向型に分類されるNoSQLデータベースで、大容量のデータを高速に処理することに主眼を置いた製品です。元々はFacebookで開発されたデータベースで
認証局を立ててぼろもうけしたいんですが＞無理な理由を理解しよう - Qiita
SSLの認証局とか証明書とか勉強し始めはホント難いよね このへんのSSL/TLSの仕組みって勉強し始めの頃は凄く難しく感じるのよね。分かりやすく解説してくれてるサイトってあんま見たこと無いし。 んで、 >>300,304 みたいなことは僕も昔考えたことあったわー、と懐かしみを覚えたのでレスってみた。 証明書を発行できるかどうかは証明書のフラグで決まっている、という >>303 の指摘も重要よね。 以下2chスレより引用 丁寧過ぎると評判のレスをしてるID:UyEJo1f2が僕なわけだがｗ 2chだとそのうち倉庫に行っちゃうかもしれないのでここにメモ。 【認証局】SSLに関するスレ 2枚目【ぼろ儲け】 http://hayabusa6.2ch.net/test/read.cgi/mysv/1286532904/298-309 298 ：DNS未登録さん：2013/05/31(金) 13:31
ヤフー株式会社様に「秘密の質問と回答」に関して要望します
拝啓、貴社ますますご清栄のこととお慶び申し上げます。日頃は格別のご高配を賜り、あつくお礼申し上げます。さて、さっそくですが、表題の件についてお願いがあり、ご連絡差し上げました。 私は東京都品川区在住の貴社サービスの一ユーザーです。Yahoo! IDの登録が2001年3月、Yahoo!プレミアムは2003年 2月からですので、十年来のユーザーと言うことになり、現在はヤフオクやYahoo! Boxを利用しております。どうぞ、お見知りおきのほど、よろしくお願いいたします。 さて、ご連絡差し上げたのは、表題に述べたように「秘密の質問と回答」に関する要望です。と言いますのは、報道などで「秘密の質問と回答」が漏洩したことを知ったからです。 ヤフーは２３日、今月１６日に不正アクセスで流出した「ヤフージャパン」のＩＤ２２００万件のうち、約１４９万件についてはパスワードと、パスワード変更のために使う「秘密の
「演算子のインジェクション」と「SSJI」
「演算子のインジェクション」と「SSJI」：NoSQLを使うなら知っておきたいセキュリティの話（1）（1/2 ページ） ここ数年、大量データ処理時の高速性やデータ構造の柔軟性などから、「NoSQL」が注目を集めています。それと同時に、NoSQLを使うアプリケーションに対する攻撃手法も研究されるようになりました。この記事では、NoSQLを使ったアプリケーションの脆弱性と対策について解説します。 注目集める「NoSQL」 ここ数年、NoSQLと呼ばれる種類のデータベースが注目を集めています。NoSQLはSQL言語を使用しないデータベースの総称で、大量データ処理時の高速性やデータ構造の柔軟性などのメリットがあるため、従来のリレーショナルデータベース（RDB）を補完・代替するものとして、大規模なWebアプリケーションなどにおいてNoSQLを採用する事例が増えています。 このような新しい技術が普及し
ssig33.com - セキュリティの話
実際に危険な例 データの変更が出来るドメインに XSS がある 秘匿されたデータが閲覧できるドメインに XSS がある 声優の住所を公開するサイトがある 実際には危険ではない例 ameblo.jp に XSS がある Twitter クライアントの Consumer Key と Consumer Secret を第三者が取得できる 声優の携帯電話の情報をブログからまとめて公開するサイトがある 後者は大して危険ではないですし、こういうものを危険だ危険だといっていると真に危険なものについて話している人の声が届くべきところに届かないことになります。 ところで実際のところ、インテリジェンスなるもの大半は公開情報を検索可能な形に編集し意味のあるデータを作成する行為であり、声優の携帯電話に対してインテリジェンスの暴力を声優に翳すなと言う批判は成立するのだと思います。 例えば鹿野優以の使っていた携帯電話
JSONをvbscriptとして読み込ませるJSONハイジャック(CVE-2013-1297)に注意
はせがわようすけ氏のブログエントリ「機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき」にて、巧妙な罠を仕掛けることにより、別ドメインのJSONデータをvbscriptとして読み込み、エラーハンドラ経由で機密情報を盗み出すという手法が紹介されました。これは、IEの脆弱性CVE-2013-1297を悪用したもので、MS13-037にて解消されていますが、MS13-037はIE6～IE8が対象であり、IE9以降では解消されていません。 また、MS13-037を適用いていないIE6～IE8の利用者もしばらく残ると考えられることから、この問題を詳しく説明致します。サイト側の対策の参考にして下さい。 問題の概要 JSON形式のデータは、通常はXMLHttpRequestオブジェクトにより読み出しますが、攻撃者が罠サイトを作成して、vbscript
補足編：機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
「機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記」の補足編です。 結局、よくわからないんだけど。 よくわからない場合は、とにかく全てのレスポンスに X-Content-Type-Options: nosniff をつけましょう。 機密情報を含むJSONにX-Content-Type-Options:nosniffをつける理由はわかったけど、「あらゆる」コンテンツにつける理由はなぜ？ 機密情報を含まなくても、<script>のような文字列を含むコンテンツをIEで直接開いた場合にはXSSにつながる可能性もあります。どのようなコンテンツにX-Content-Type-Options:nosniffが必要かを考えるくらいであれば、全てのコンテンツに付与したほうが間違いがなくていいでしょう、ということです。 IEのためだけの問
[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ
SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 単にプリペアドステートメントを使え 絶対に文字列結合でSQLを構築しようとしてはいけない IPAの「安全なSQLの呼び出し方」を読むこと なんでこんなことを書くかというと、同僚が献本されてた「プロになるためのWeb技術入門」なる本のSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。 a) 値をバリデーションする b) プリペアドステートメントを使う ダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。 単にプリペアドステートメントを使え 文字列結合でSQLを構築するな イケてない本を書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか？値のバリデーション
![[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ](https://cdn-ak-scissors.b.st-hatena.com/image/square/abd76f3bb0ec0750428a791cbfbf7959c317f97d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127052840568%2F17680117127052842215%2F1555633900)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
他人事ではないWebセキュリティ
XSS再入門
情報セキュリティWiki - セキュアなWebアプリケーション構築のために
就活生のみなさんへ ～文系？理系？～ « サーバーワークス社長ブログ
