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暗号
sshでポートフォワード
sshには言わずと知れた「ポートフォワード」という機能があります。 読んで時の如しで、sshの暗号化されたトンネルを利用し、任意のポートに来た通信を転送できます。 何がうれしいかと言うと、リモートの 5432番 をローカルの 5432 にマッピング出きる。 つまり、sshさえ繋がれば、そのサーバから見える範囲ならなんでも使える！と言うことです。 1・ローカルへリモートのポートをマッピング 例えば、二つのホスト（chiba, shiga）があるとします。 chibaに、shigaの5900ポートをフォワードする場合は以下のようになります。
SSH ポートフォワーディング
ポートフォワーディング（port forwarding）とは、ローカルコンピュータの特定のポートに送られてきたデータを、別な通信経路を用いてリモートコンピュータの特定ポートに送信する事です。 この通信経路には、SSHを利用する事が多いです。 SSHの通信路を使用することによって、通信を暗号化することができます。 通信のイメージは図のようになります。 通常は、各アプリケーションが、それぞれのポートを使用して暗号化されていない平文で通信を行います。 しかし、このままではパケットの盗聴などセキュリティに危険が生じます。 そこで登場するのが、”SSHを利用したポートフォワーディング（Port Forwarding）”です。 この方法によって、通信は暗号化されたSSHの経路を通ります。 従って、平文よりも安全性を高める事ができます。 では、実際の通信の経路を追ってみましょう。 通常の通信では、各アプ
SSH力をつけよう
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 RFC 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints RFC 4256 Generic Message Exchange Authent
Windowsから公開鍵認証でSSH2サーバにログインする（PuTTY編）
対象OS：Windows 2000／Windows XP／Windows Vista／Windows 7／Windows Server 2003／Windows Server 2008／Windows Server 2008 R2 解説 レンタルサーバやUNIX／Linux／FreeBSDベースのサーバでは、各種設定やメンテナンスにSSH2サーバが使われていることが多い。しかしWindows OSはSSH2サーバに接続する機能を持っていない。 そこでTIPS「Windowsでsshクライアント「PuTTY」を使う」では、Windows用SSH2クライアントソフトウェアの1つ「PuTTY」を使って、Windows OSからSSH2サーバに接続する手順を説明した。 このTIPSでは、サーバの初期セットアップ時によく利用されるパスワード認証を例に取り上げた。しかしSSH2は、この他の認証方式もサ
Debian上でのiptablesの設定方法 - インターネッツの砂浜でスカベンジャー
ネットでググると古い記事が多いので、Debian Wikiを参考に簡単な方法を書いてみます。 aptitude install iptables iptables-persistent まず、iptablesとiptables-persistentをインストールします。 iptables-persistentは後で役立ってきます。 iptables -L 早速、現在の設定を見てみると Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destinationこのように空っぽの状態だと思い
ssh公開鍵認証手続き
SSH公開鍵認証手続き （１）ssh公開鍵の手続きについて （１）−１ UNIX(Linux) 版 （１）−２ Windows 版 （２）scp,sftpについて 2005.11.16 WinSCPでSCPプロトコルを選択した場合の注意事項追記 2005.8.9 WinSCPでRSA1鍵を使用する場合の注意事項追加 2005.8.9 サーバーのホームのモードが「755」以下である必要があることを追記 （１）ssh公開鍵の手続きについて 公開鍵による認証手続きとは、ユーザー端末で、公開鍵と秘密鍵のペアを作成し、公開鍵をリモートホスト（サーバー側、ここではLHD数値解析システム）の所定の場所におきます。ログイン時にはこの公開鍵と秘密鍵とを使って認証します。付加的ですがログイン時のパスフレーズ入力もセキュリテイ強化に有効です。 ここで紹介するsshのバージョンはバージョン１のRSA1と
いまさら聞けないパスワードの取り扱い方
そうだったのか！ よくわかる process.nextTick() node.jsのイベントループを理解するshigeki_ohtsu
websec-room.com - websec room リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ディレクトリトラバーサル攻撃への対処 - 自分の仕事を憎むには人生は余りにも短い
ディレクトリトラバーサル攻撃を検知する場合「../」を検知するとかではダメで以下のIPAのサイトにあるようにちゃんとしたチェックが必要。 http://www.ipa.go.jp/security/awareness/vendor/programming/b07_07.html 必要なのは以下の精査。 パス名を正規化し、正規化する前と比較し一致すること パス名の各階層のディレクトリが実際に存在すること パス名の各階層のディレクトリのオーナやグループ，ファイルモードが適切であること パス名中にシンボリックリンクが含まれていないこと このうち パス名の各階層のディレクトリが実際に存在すること パス名の各階層のディレクトリのオーナやグループ，ファイルモードが適切であること の2件は普通にチェックするだけなのだが、シンボリックリンクかどうかを検証するのと、 正規化したものが一致するかどうかを検証す
rack-protection とは - Qiita
rack-protection とは，Sinatra 関連のコンポーネント (sinatra-contrib など) を多数作ってる rkh 氏のプロダクトの一つで，Rack に組み込むだけでいくつかの脆弱性に対する防御をしてくれる Rack middleware です。 いかがかなと思うコンポーネントもありますが，基本的にそういうのはデフォルトで無効化されてますし，FrameOptions や XSSHeader のように「とりあえず入れといても副作用ないし実効性がある」コンポーネントも多いので，とりあえずいれとくというスタンスでもよいのではないでしょうか。 使い方 ざっくりと省略。 とりあえず説明ページにあるように，config.ru に書く場合， な感じで使うことになります。この Rack::Protection を use すると，バンドルされているコンポーネント (middlew
本当は怖いパスワードの話
「パスワードはハッシュで保存すれば安全」と思われていますが、本当にそれだけで大丈夫なのでしょうか？ この記事では、パスワードを安全に守るソルトやストレッチングといった手法について解説します（編集部） (3/4)
Rails 3.1: has_secure_passwordメソッド
この前のエントリーでは、Rails 3.1で登場した assign_attributes という渋いメソッドについて書きました。 今回紹介するのも渋い新仕様です。その名も has_secure_password。 いま、User というモデルがあるとします。データベーステーブル users には name password_digest という2つのカラムがあります。いずれも文字列型です。 app/models/user.rb を次のように書き換えます。 class User < ActiveRecord::Base has_secure_password end これで準備完了です。 rails c でRailsコンソールを起動してください。 まず、Userオブジェクトを作ります。 > User.create!(:name => "tsutomu", :password => "jumb
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - sinatra/rack-protection: NOTE: This project has been merged upstream to sinatra/sinatra