cmd.exeのせいで子プロセス呼び出しが脆弱になっちゃう件 - Qiita
TL;DR cmd.exeはカレントディレクトリーにあるファイルをPATHにあるファイルより優先して実行してしまうと言うクソ仕様なので気をつけよう。 安全のために、vim-gitgutterを使っている人は以下の設定を追記しよう。 if has('win32') " Git for Windowsをデフォルトでインストールした場合。お使いの環境に合わせて変えること。 let g:gitgutter_git_executable = 'C:\Program Files\Git\bin\git.exe' endif 当然、ほかにも危険なVimプラグイン（など）がたくさんあると想定される。ほかのコマンドを呼び出すソフトウェアを書く際は、少なくともWindowsで使用されることを想定する場合は、極力shell経由で呼び出すAPIは使用しないこと。自動でcmd.exeが使用され、脆弱性になり得る。
hashdos脆弱性とunordered-containers - Haskell-jp
HashMap・HashSetの利用時は注意！Posted by Yuji Yamamoto(@igrep) on January 21, 2018Tags: Security あらゆるソフトウェアに脆弱性は存在し得ます。 Haskellは高度な型システムを駆使することで、脆弱性を根本的に回避したプログラムを作ることを可能にします（脆弱性を防ぐためだけのものではないですが、興味のある人はSafe Haskellについても調べてみるといいでしょう）。 しかし、だからといって、型を設計する段階で脆弱性を回避できるよう気をつけなければいけないことには変わりませんし、GHCが生成した実行ファイル、使用するライブラリーに絶対に脆弱性がないとは言えません。 現状、Haskellはほかの著名なプログラミング言語ほど使用されていないためか、あまり脆弱性が報告されることはありません（libcなど、ほかの言語
Object#send 有害論 - Qiita
ご存知の方には何を今更感があるかとは思いますが、パッとググった限り誰も書かれていなかったので、 Object#sendやそれとよく似たObject#public_sendの使い方は注意して使わなければ結構危ないセキュリティホールを作ってしまうよ、 というお話をしたいと思います。 TL;DR Object#sendはevalやsystemの次ぐらいに危険です。ユーザーの入力など、外部から入力された値をObject#sendやpublic_sendメソッドにそのまま渡すのはやめましょう。 これらのメソッドに渡す文字列は、（特殊なメタプログラミング用のライブラリを作る場合などを除いて）必ずどこかにハードコードした、信頼できるメソッドの名前のみにしてください。 危険なケース 例えばあからさまな例ですが、次のようなRailsのコントローラーのアクションがあったとしましょう。 みなさんはこれに近いよう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
