商用環境で設定しておきたいセキュリティ関連 HTTP ヘッダまとめ - A Memorandum
TL;DR X-Content-Type-Options X-Frame-Options(XFO) X-XSS-Protection Content-Security-Policy (CSP) Upgrade-Insecure-Requests Strict-Transport-Security (HSTS) Public-Key-Pins (HPKP) 設定 TL;DR X-Content-Type-Options MIME スニッフィングの無効化 X-Frame-Options(XFO) フレーム表示を制限しクリックジャッキングを予防 X-XSS-Protection XSSフィルタの有効/無効 Content-Security-Policy (CSP) XSSなどの攻撃を軽減するセキュリティレイヤー Strict-Transport-Security (HSTS) HTTP の代わり
hostsにループバックアドレスを指定することでリスクが増大するケース
前のエントリhostsファイルにループバックアドレスを指定することは危険か?で、hostsにループバックアドレス（127.0.01）を記述することは危険とは言えないと書いたのですが、その後malaさんとkazuhoさんから、レアケースではあるがリスクの増加はあるよという指摘を受けました。 議論の想定は、Android端末のローカル上にWebアプリケーションが動いており、それに対する攻撃が可能か否かを検討するものです。この状態で、利用者が広告よけを目的としてhostsファイルを修正して、example.comを127.0.0.1に指定しようとしていると仮定します。 まず、malaさんの指摘ですが、Google+に読者限定で投稿されています。このエントリは読めない方が大半なので以下に転載します（転載の許諾はいただいています）。…と思ったらmalaさん自身が見える場所に転載いただいたいました。こ
さくらDNSにサブドメインハイジャックを許す脆弱性
さくらインターネット株式会社のDNSサービスにセキュリティ上の問題がありましたが、改修されましたので報告します。 DNSサービスへのドメイン登録時における不具合について 障害内容 : 当社の提供するネームサーバサービスにおいて、既に登録されているドメインのサブドメインが、他の会員IDの方に登録できる状態となっておりました。この障害により、悪意のある第三者がドメインの一部を乗っとれる脆弱性につながる危険性がありました。 本問題につきましては現在は解消されており、全ての登録について不正がないかの調査を行っております。 この問題の発見者は前野年紀氏で、私はさくらインターネット株式会社に問題を通告し、改修を促すための連絡などでお手伝いをしました。 (12:00追記)なお、この脆弱性が混入したのは6月8日頃で、さくらインターネットは6月11日から修正を開始し、昨日（6月13日）には改修されましたので
最終回 セキュアなSSHサーバーを構築する
これまで構築してきた自宅サーバーによるサービスを，外出先からも利用できたら便利だ。そこで今回は，SSHサービスとポート・フォワードを設定し，外からも自宅サーバーを使えるようにしてみよう。 連載の最後となる今回は，自宅サーバーでSSH（Secure Shell）サービスを稼働させる。SSHは，外部から自宅サーバーへのリモート・ログインを可能にするサービスだ。このSSHとポート・フォワード機能を併用すれば，SSHで接続したクライアントはLAN内に設置したように，メールやWebなどのサービスを利用できる。 もちろん外部向けのサービスを稼働すれば，それだけ攻撃を受ける可能性が高くなる。そこで，よりセキュアに運用できるよう，公開鍵（かぎ）認証やファイアウオールを設定したSSHサーバーを構築しよう。 SSHの認証方法 SSHを使って，外部からリモート・ログインを行うときのユーザー認証では，パスワード認
5分でできるPHPセキュリティ対策 - ぼくはまちちゃん！
こんにちはこんにちは！！ Webプログラミングしてますか！ よく「PHPはセキュリティがダメ」とか言われてるよね。 でもそれって、べつにPHPが悪いんじゃなくて、 たぶん、セキュリティとかが、まだよくわからない人が多いだけなんじゃないかな。 がんばって勉強しようと思っても、なんだか難しい理屈が並んでいたりするしね…。 なので今日は、セキュリティ対策について、 「これだけやっとけば、わりと安全になるよ」ってことを、初心者むけに、大雑把に書いてみます！ 理屈がわからなくても、最初はコピペでも、 なにもやらないより、やったほうがきっとマシになる！ 1. XSS対策 動的なものを表示するとき、全部エスケープすればokです！ (NG) あなたの名前は <?= $name ?> ですね！ ↓ (OK) あなたの名前は <?= htmlspecialchars($name, ENT_QUOTES) ?>
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
大規模 Web サービスでログインを長期間保持するには SESSION は使わず Cookie とデータベースだけで実装する | ウェブル
先日ペコリンという Web サービスを公開したのですが、これが初めての WordPress との複合会員向けサービスだったためか、ログインが途中で切れたり、記事投稿時のリダイレクトがかかるタイミングなどで SESSION が切れてしまうことがありました。 しかし Twit Delay では長期的にログインが保持されていたり、mixi とかではログイン時間を指定できたりするので、なんとかできるものだろうと考えていたら Twitter で教えてもらいましたのでまとめておきます。 SESSION だけを使ったログインの保持では長期ログインは不可 私は今までログインの保持は以下のようにしていました。 1 2 3 4 5 <?php ini_set('session.gc_maxlifetime', 60*60*24); ini_set('session.gc_divisor', 10000); s
SSL認証局が偽の証明書を発行、大手サイトに影響の恐れ
SSL認証局のComodoから偽のSSL証明書が発行され、Microsoft、Google、Yahoo!など大手各社のWebサイトが影響を受ける恐れがある。攻撃を防ぐためにWindowsやFirefoxのアップデートが公開された。 SSL認証局のComodo Groupが偽のSSL証明書を発行し、Microsoft、Google、Yahoo!など大手各社のWebサイトが影響を受ける恐れがあることが分かった。MicrosoftやMozillaはアップデートを配信し、攻撃を防止する措置を取っている。 Microsoftによると、Comodoは偽のSSL証明書を9件発行したという。影響を受けるのは、Hotmailのログインに使われている「login.live.com」のほか、Googleの「mail.google.com」「www.google.com」、Yahoo!の「login.yahoo.
セキュアプログラミング for Linux and Unix HOWTO
この文書は、Linux および Unix システム上で安全なプログラムを書く際に必要と なる設計や実装について、そのガイドラインを提供します。 遠隔のデータを見るためのビューアーや Web アプリケーション(CGI スクリプト を含む)、ネットワーク・サーバ、setuid や setgid してあるプログラムが対象です。 C や C++、Java、Perl、PHP、Python、TCL、Ada95 個別のガイドラインも掲載します。 Table of Contents1. はじめに2. 背景2.1. Unix や Linux、オープンソースもしくは フリーソフトウェアについて2.2. セキュリティの原則2.3. なぜプログラマは危ないコードを書いてしまうのか2.4. オープンソースはセキュリティに効果があるのか2.5. 安全なプログラムの種類2.6. 疑い深く、こだわりが強いことに価値がある
今更だけどDNSキャッシュポイズニングについて簡単に説明するよ！ - そして、DNSポイズニングがなかなか対応されない理由。 - FreeBSDいちゃらぶ日記
先日IIJの一日インターンに行ってきました。 NDAがあるので、事細かに書くことは出来ないのですが、教育的なプログラムが組まれていて非常に面白かったです。 そこで、色々お話しして、その中でDNSポイズニングがなかなか対応されない理由、当たり前の理由が聞けたので、「DNSポイズニングって何がヤヴァイのか良くわかんね」って人に向けた簡単な解説とあわせて書きたいと思います。 まず、DNSキャッシュポイズニングの何が怖いか? 簡単に言うと、 「googleに繋いだはずが全く別サイトに繋がっちゃう！」 って話です。 本当に繋ぎたいサイトと違うサイトに繋いじゃう事が出来るので、例えば 実在するショッピングサイトそっくりの偽サイト作って、ショッピングさせて。クレジットカードの番号ゲットしちゃったり、住所ゲットしちゃったり。 夢が広がる怖い事が出来ちゃいます。 きちんとしたセキュリティ対策していれば大丈夫
高木浩光＠自宅の日記 - 無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者
馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する（閲覧者が望めば https:// でも閲覧できるようにする）のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。 （8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。） それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。 こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。 つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに
高木浩光＠自宅の日記 - 日本のインターネットが終了する日
■ 日本のインターネットが終了する日 （注記：この日記は、6月8日に書き始めたのをようやく書き上げたものである。そのため、考察は基本的に6月8日の時点でのものであり、その後明らかになったことについては脚注でいくつか補足した。） 終わりの始まり 今年3月31日、NTTドコモのiモードが、契約者固有ID（個体識別番号）を全てのWebサーバに確認なしに自動通知するようになった*1。このことは施行1か月前にNTTドコモから予告されていた。 重要なお知らせ:『iモードID』の提供開始について, NTTドコモ, 2008年2月28日 ドコモは、お客様の利便性・満足の向上と、「iモード(R)」対応サイトの機能拡充を図るため、iモード上で閲覧可能な全てのサイトへの提供を可能としたユーザID『iモードID』（以下、iモードID）機能を提供いたします。 （略） ■お客様ご利用上の注意 ・iモードID通知設定は
パソコンを安心して使うために。セキュリティ啓発コンテンツ (Microsoft) の PDF 文書のプロパティのタイトルが「女医マイ子_表紙」である件について。 - セキュリティホール memo
》 ＜訃報のご連絡＞萩野純一郎（享年三十七歳）が１０月２９日、夜に永眠致しましたので慎んでご通知致します (hoge.org)。そ、そんな……若すぎる……。残念です。合掌。 関連: itojun.org itojun氏、逝去 (slashdot.jp, 10/31) 訃報：萩野純一郎氏 (WIDE プロジェクト, 10/31) 》 友達の友達はアルカイダ ? 鳩山法務大臣文書で報告へ (保坂展人のどこどこ日記, 10/31) 》 不正を起こせる環境にした責任 (まるちゃんの情報セキュリティ気まぐれ日記, 10/31) 》 出会い系サイト、子供の被害防止へ警察庁が研究会 (読売, 10/31) 》 東電：９５０億円の最終赤字見通し 柏崎刈羽復旧などで (毎日, 10/31) 》 猛暑で養殖カキ９割死滅 風物詩の焼き小屋ピンチ 長崎 (asahi.com, 10/31) 》 広島に１メガトン核
高木浩光＠自宅の日記 - 通信路上の改竄攻撃発生に、Webサイト運営者が説明責任を負うのか？
■ 通信路上の改竄攻撃発生に、Webサイト運営者が説明責任を負うのか？ セキュリティホールmemoにまとめられているように、レンタルサーバのさくらインターネットのLAN上で、ARP spoofing攻撃が発生したのではないかとの疑いが浮上している。しかし、現時点でさくらインターネットは公式にそれを認めておらず、誰も確かな情報として伝えることができない状態にある。 昨今、Webサイトのコンテンツを改竄されて、ウイルスファイルへのインラインリンクを埋め込まれる手口の被害が多発しており、その際、Webサイトを改竄されたサイト運営者は、サイトを訪れた一般利用者に対してウイルス感染に注意を呼びかける告知を出すというのが、慣例になりつつある。これは、サイト運営者がサイト管理の不備を詫びる意味も含めて、行われている発表であろう。 しかし、ARP spoofingによる「改竄」は、Webサイトのコンテンツ
＠IT：止められないUNIXサーバの管理対策 第5回 （3） ～管理者権限の制限のためのsuとsudoの基本～
※ご注意 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 前回は、すべてのコマンドが使用できてしまう特権ユーザー（スーパーユー ザー）の利用制限について説明した。今回は、引き続き特権ユーザーが通常行うsuのセキュリティ上の問題点やsudoの基本的な使い方について紹介する。 suの問題点 suコマンドは、再ログインになしにrootに限らず任意のユーザーにスイッチすることができるという、とても便利なコマンドだ。しかし、そんなsuコマンドには、以下に示すようなことが懸念されている。 ●rootのパスワードを入力する必要がある suコマンドは、実行時にスイッチするユーザーのパスワードを入力する必要がある。例えばtelnetでリモートログ
ローカルファイルのセキュリティ警告を出さないおまじない
Libraのハッカソンやってるという話は先日「HackLibra、最初のオンラインハッカソン」で書きました。 …
高木浩光＠自宅の日記 - 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと
■ 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと 「コンピュータセキュリティを基礎から」というと、暗号の解説、特に共通鍵暗号と公開鍵暗号の違いからなどといった解説をよく目にする。昔は専門の方によって注意深く書かれていたのに対し、ここ何年かはひどい状況になっている。先月、宮崎で開かれたSCIS 2008の席でも暗号研究者の方々との雑談でそういう話になった。私は暗号は専門でないのでその話題は迂闊に書けないできたが、このところの巷の誤り解説の氾濫ぶりは目に余るものがある。 最もひどく蔓延っていてしばらく消えそうにない間違い解説の典型例は次だ。 「公開鍵で暗号化したものを秘密鍵で復号するのと同様に、秘密鍵で暗号化したものを公開鍵で復号できるようになっている。」 事例1: 日本ベリサイン株式会社による公開鍵暗号方式の解説 このような共通鍵暗号方式の問題点を解決する暗号方式が、公開鍵暗号方式
ユーザの実行権限を柔軟に割り当てるsudoのリスクとメリット | OSDN Magazine
セキュリティ関連のジョブにいささかでも関わりを有す者であれば、root権限ないしrootパスワードを一般ユーザに与えるのは御法度であると心得ているはずだ。しかしながら、正当な理由をもってroot権限下での処理を実行する必要に迫られた一般ユーザが出てきた場合はどうすればいいのだろうか？ そうした問題には非常にシンプルな解答が存在する。sudoを使えば、rootパスワードを公開することなくアクセス範囲を最小限化した上で必要な権限を一般ユーザに与えることができるのである。 sudo（superuser doの略）とは、管理権限を制限付きで他のユーザに与えるためのプログラムで、実際これで許可される権限では事前の指定範囲内のコマンドしか行えないようになっている。またsudoで行われる操作はすべてオーディットトレール（追跡記録）に残されるので、仮にこうしたユーザが何らかの方法で権限外の処理を行ったとし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ARPスプーフィングで通信傍受！ | The Weekly Herald
IPA セキュア・プログラミング講座