Composer のセキュリティ上の問題が直ったので PHP な方は今すぐ更新を - co3k.org
Composer の以下の問題が 2 月半ばあたりから話題になっていました。 Limit Replace / Provides to packages required by name in root package or any dep · Issue #2690 · composer/composer https://github.com/composer/composer/issues/2690 一言で言うと、 条件によってはユーザの意図しないパッケージがインストールされてしまう という問題です。悪意のあるパッケージをインストールしたことに気づかれなければ、攻撃者の思い通りのコードを実行させることができてしまいます。 ざっくり説明すると、 Composer には fork したパッケージや、リネームしたパッケージ から 、元のパッケージを置き換えることのできる機能が存在する (本エン
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
Python 製の負荷試験ツール Locust を試してみた - co3k.org
Web の負荷試験ツールとして代表的なのは Apache JMeter だと思いますが、 Apache JMeter 自体が結構重いのと、テストシナリオの保守が GUI ツールでは結構ツライ (シナリオファイルは XML ですが、とても人間が手を加えられるような代物じゃない) なあということで代替となるものを探していました。 で、心惹かれたのが以下のツールです。 Gatling Tsung Locust Gatling は非常によさそうなんですが、うーん要 JDK か……あとは複数台から負荷を掛けることができないというのもちょっとマイナスですね。まあどっちもどうにかしようと思えばどうにかなるポイントではあるんですけど。 Tsung は Erlang 製で、仕事で Erlang 使う可能性も出てくる気がするのでこれで慣れ親しんでおくのもいいかなーと思ってシナリオファイルを覗いてみたら ド直球
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
