Rails SQL Injection Examplesの紹介
6. 脆弱性のあるアプリケーション Copyright © 2010-2014 HASH Consulting Corp. 6 @books = Book.where( "publish = '#{params[:publish]}' AND price >= #{params[:price]}") 山田 祥寛 (著) Ruby on Rails 4 アプリケーションプログラミング 技術評論社 (2014/4/11) に脆弱性を加えましたw ※元本に脆弱性があるわけではありません 7. UNION SELECTにより個人情報を窃取 Copyright © 2010-2014 HASH Consulting Corp. 7 priceに以下を入れる 1) UNION SELECT id,userid,passwd,null,mail,null,false,created_at,updated
CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
新しい暗号技術
2. 自己紹介 大学時代 京都大学数理解析研究所では代数幾何 コンピュータとは縁のない世界 暗号にも興味を持つ mp3エンコーダ「午後のこ～だ」の開発(LGPL2) 就職後 IPAからの依頼で暗号解読プログラムの作成(2004年) 『機械学習の学習』(CCA-BY3) 2012年ジュンク堂のコンピュータ書籍売り上げ3位 http://compbook.g.hatena.ne.jp/compbook/20130110 暗号の高速な実装(2013/8の時点で世界最速) The Realm of the Pairings(SAC2013) http://sac2013.irmacs.sfu.ca/sched.html 2013/11 2 /58 3. 目次 暗号 mod pの世界 巾乗の計算 離散対数問題 ElGamal暗号
続・$HOME/.ssh/configを活用していますか？ — ディノオープンラボラトリ
以前の記事「$HOME/.ssh/configを活用していますか？」では、設定ファイルを少し頑張って書けば普段のSSHライフが随分変わりますよ、と紹介しました。今日はその続編です。前回よりマニアックな設定を紹介します。 2段以上先のサーバにログインする Dynamic Forward機能を使う 共通設定をまとめて書く 2段以上先のサーバにログインする 目的のサーバにログインするために、踏み台的なサーバを経由しないと入れない環境があります。例えば、dmz経由でないとDBサーバにログインできない環境、というのは良くある構成でしょう。 このような場合に、ProxyCommandパラメータが利用できます。 上の設定で「ssh db1」とすると、sshでdmzに接続し、dmzから192.168.0.201へログインします。これを利用するには踏み台サーバにncコマンドが必要ですが、大抵の環境にインスト
特定のサーバを踏み台にして別のsshサーバに接続する (ProxyCommand) | maeda.log
2010-01-21 23:08 | tag: linux インターネット上のサーバのsshdの設定で、接続できるホストのIPアドレスを限定するという運用は多いと思います。このような運用を行っている場合、目的のサーバに接続するためには、以下のように一旦プロキシ（踏み台）サーバに接続して、あらためて目的のサーバに接続するという操作となり、やや煩雑です。 ■概念図 |クライアント| --(ssh)--> |プロキシサーバ| --(ssh)--> |目的のサーバ| ■手順 1. クライアントからプロキシサーバに対してsshで接続、ログイン。 (user_proxyはプロキシサーバ上のユーザー) $ ssh user_proxy@proxy.example.jp 2. プロキシサーバからクライアントに対してsshで接続、ログイン。 (user_destは目的のサーバ上のユーザー) $ ssh us
SSHD (8)
OpenSSH SSH デーモン 書式 sshd [-46DdeiqTt ] [-b ビット数 ] [-C 接続指定 ] [-f 設定ファイル ] [-g ログイン制限時間 ] [-h ホスト鍵ファイル ] [-k 鍵の生成間隔 ] [-o オプション ] [-p ポート ] [-u 長さ ] 説明 sshd (OpenSSH デーモン) はssh (1) のためのデーモンプログラムです。これらのプログラムはともにrlogin とrsh を置き換えるもので、安全でないネットワーク上にある、2つの信頼されていないホスト間で、暗号化された安全な通信を提供します。 sshd はクライアントからの接続を listen します。通常、これはブート時に/etc/rcから起動され、接続を受けつけるたびに新しいデーモンが fork します。fork したデーモンは、鍵の交換、暗号化、認証、コマンド実行、そ
SSH のダイナミック転送ってすごいんですよ | Typemiss.net
DSAS開発者の部屋:OpenSSH クライアントの proxy -- 踏み台サーバを経由しての ssh nc と ProxyCommand を使うというアイデアは今まで見たことが無く，なるほど！と感心しました。ですが，もっと便利な方法があります。ssh -Dはすごい便利です。SSH のほかにも色々できますし，中継サーバを「転送専用」と割り切ってしまえば，管理がとっても楽になり，セキュリティレベルを高く保つことも容易になります。他で情報を見かけないので，そのうち書こうと思っていたのですが，せっかくなので書いてしまいましょう。 はじめに：ssh の多段接続問題 DSAS開発者の部屋:OpenSSH クライアントの proxy -- 踏み台サーバを経由しての ssh のように，ssh の多段接続を行いたいという要求はあちこちであるかと思います。私の所属している研究室の場合は，計算用クラスタとい
SSH力をつけよう
2. もくじ ► おさらい ► クライアント(ssh/scp)の話 ポート転送の話 多段ssh その他の転送の話・他のオプション ► サーバ(sshd)の話 ► ちょっとした疑問 ► セキュリティの話 ► まとめ 2 / 62 5. RFC RFC 4250 The Secure Shell (SSH) Protocol Assigned Numbers RFC 4251 The Secure Shell (SSH) Protocol Architecture RFC 4252 The Secure Shell (SSH) Authentication Protocol RFC 4253 The Secure Shell (SSH) Transport Layer Protocol RFC 4254 The Secure Shell (SSH) Connection Protocol RF
UDIDとUUIDの違いをざっくりと - 前人未踏の領域へ Androidアプリ開発編
UDID 携帯端末などに個別に割り当てられるID どのアプリケーションからUDIDを取得しても同じ値が得られる 異なるサービスを運営していても、同じUDIDが使われていれば同じユーザーによるものであることが推測できる 個人情報管理上問題がある。 UUID ランダムに割り当てられた値 全世界でIDが重複しない程度に桁数が大きい アプリケーション(サービス)ごとに都度発行する仕組み アプリケーション(アプリ内データ)を削除してから再取得すると異なる値が発行される。 各アプリケーション間で発行されるUUIDには関連がない 結論 アプリケーション開発者はユーザーごとに個別のIDを割り当てたい場合にはUDIDではなくUUIDを使うべし。 再取得時には値が変わるので変更に対応したシステム設計が必要。
＠IT：Webアプリケーション: 第3回 気を付けたい貧弱なセッション管理
※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。 また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 「第2回 顧客データがすべて盗まれる」は、クロスサイトスクリプティング（XSS）と同様に実際のプログラミングを行うプログラマの責任であるという対策で、最も危険と思われるSQL InjectionとOS Command Injectionについて紹介した。今回は、プログラミング以前の設計段階で潜り込むセキュリティホール――見落としがちなセッション管理の脆弱性について説明していく。 We
いまさら聞けないパスワードの取り扱い方
2. 本日お話ししたいこと • パスワードの器の要件 • パスワードの中身の要件 • パスワード入力画面の要件 • 認証エラーメッセージの要件 • パスワードの保存方法 2Copyright © 2013 HASH Consulting Corp. 4. SMBCダイレクトはアカウント回復に手間をかけることで対応? 4Copyright © 2013 HASH Consulting Corp. http://www.smbc.co.jp/kojin/otetsuduki/anshou/saihakko/index.html • SMBCはアカウントロック後のアカウント回復を書面あるいは電話とする ことで、オンラインのパスワード攻撃に対策していると考えられる。 • 自動的にアカウント回復するサービスの場合は、パスワードの要件を厳し くすることで、オンラインパスワード試行に対抗した方がよい •
load() を使うと Chrome が文句言う - 積極的にメモっていく姿勢
アルバイト先でウェブページを書くことになったのですが、その時のつまずきポイントのうちの一つです。 jQueryにはhtmlファイルを読み込んで埋め込んでくれる、load() メソッドというものがあります。 ファイルを別にして編集できるので、割と重宝していたのですが、Chromiumベースのブラウザでのみ遭遇するエラーというものに、時間を持っていかれました。 エラーの内容は XMLHttpRequest cannot load 場所とファイル名 Origin null is not allowed by Access-Control-Allow-Origin. 最初は、権限がないとかパスが間違っているとか、そんな程度かと思っていたので、余計時間を食いました。（最初から調べるべきだったのです。） さて、こいつを解消してやるにはどうすればいいのでしょうか。 1.そもそも何でエラーでるの Chro
ディレクトリトラバーサル攻撃への対処 - 自分の仕事を憎むには人生は余りにも短い
ディレクトリトラバーサル攻撃を検知する場合「../」を検知するとかではダメで以下のIPAのサイトにあるようにちゃんとしたチェックが必要。 http://www.ipa.go.jp/security/awareness/vendor/programming/b07_07.html 必要なのは以下の精査。 パス名を正規化し、正規化する前と比較し一致すること パス名の各階層のディレクトリが実際に存在すること パス名の各階層のディレクトリのオーナやグループ，ファイルモードが適切であること パス名中にシンボリックリンクが含まれていないこと このうち パス名の各階層のディレクトリが実際に存在すること パス名の各階層のディレクトリのオーナやグループ，ファイルモードが適切であること の2件は普通にチェックするだけなのだが、シンボリックリンクかどうかを検証するのと、 正規化したものが一致するかどうかを検証す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
GitHub - sinatra/rack-protection: NOTE: This project has been merged upstream to sinatra/sinatra