はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『

PHP Advent Calendar 2023の18日目の記事です。 PHPカンファレンスに登壇した記録を書きたいと思います。数えてみますと、2009年から昨年（2022年）までのPHPカンファレンス14回と、北海道2回、関西1回の合計17回登壇したことになります。 最初の登壇は14年前ですので、私の考えも当時からは変化していますので、そのあたりも触れながら紹介していきたいと思います。 PHP カンファレンス 2009 最初の登壇は2009年のPHPカンファレンスでした。この年はビジネスデイとテックデイに分かれていまして、ビジネスデイで登壇依頼を頂きましたので、当時温めていた「ウェブサイトを発注する際のセキュリティ」についてお話しました。 スライドの中で「脅威分析やってもあまり意味ない」みたいな物騒な意見が書いてあります。当時はそのように考えていたわけですが、これは当時のサイトがECサイ

この記事は、以下の問題の想定正解です。まだ問題を読んでいない方は、先に問題を読んでください。 ペッパー(pepper)というのは、ハッシュ計算前のパスワードに付与する秘密かつ固定のソルトのことです。ペッパーの機密性が保たれている限り、ハッシュ値からパスワードを復元することも、パスワードのハッシュ値（アプリ側で受付られるもの）を計算することもできません。 また、この問題の先行問題の知識も必要ですので以下の記事（および問題）も読んでおいたほうがよいでしょう。 さて、このペッパー付きの問題も多くの方に記事を読んで頂き、また解答もいくつかいただきましてありがとうございます。 出題時の以下条件を満たす想定解答を2種類（細かく分けると3種類）紹介します。 できればブラックボックス（つまりソースコードやテーブル定義を見ない）で解く ペッパーは覗き見してはいけない sqlmap等のツールは使っても良い s

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセス

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『

PHPのバージョン 主なコンテンツ（脆弱なスクリプト）はPHP 5.3.3（CGIモード）で動いています。これは、古いPHPでないと発現しない脆弱性に対応するためで、代表的なものとしてNULLバイト攻撃があります。PHPは5.3.4以降でNULLバイト攻撃に対応したため、NULLバイト攻撃を体験するにはPHP 5.3.3以前のものを使う必要があります。一方、新しいバージョンのPHPが必要な箇所もあり、その場合はPHP7.0.27（Debian9標準パッケージのもの）を使い分けています。 メール関連の脆弱性対応 メールヘッダ・インジェクションを体験するにはメールの送受信の仕組みが必要なため、Postfix、Dovecot、RoundCubeがインストールされています。徳丸本初版は「お手元のメールクライアントソフトをお使いください」という体でしたが、今どきメールクライアントを使っている人も少な

昨日、上野宣（@sen_u）さんがパスワードの総当りに要する時間の表をツイートされ、話題になっています。 総当たり攻撃時のパスワード最大解読時間の表を日本語化した。https://t.co/cVSNUZkAKv pic.twitter.com/rtS8ixwOqi — Sen UENO (@sen_u) August 17, 2021 1万件を超えるリツイートがありますね。大変よく読まれているようです。しかし、この表は何を計測したものでしょうか。上野さんにうかがってもわからないようでした。 何ですかね？パスワード空間が大きくなると解読に時間が掛かるということくらいがわかりますかね。 — Sen UENO (@sen_u) August 17, 2021 一般に、パスワードの総当たり攻撃（ブルートフォースアタック）というと、以下の二通りが考えられます。 ウェブサイト等でパスワードを順番に試す

以下の記事を読みました。 CookieのPath属性は本当に安全性に寄与しないのか 結論として以下となっています。 結論。Path属性は特殊な状況下ではある程度安全性に寄与する Path属性は、これを設定してCookieを発行するあるパス(以下「自身のパス」)にサーバサイドのプログラムを書き換えられるような脆弱性がなく、同一オリジン内の別のパスにそのような脆弱性がある場合に、そのパスへのCookieの漏洩することを防ぐことができます。 中略 つまり、「体系的に学ぶ 安全なWebアプリケーションの作り方」の記述はおそらく間違えです。 とはいえ私はセキュリティは専門ではなく、特に攻撃側には疎く、この記事に書いた以上の調査・実験もしていないため、この結論も確実とは言い切れません。詳しい情報をお持ちの方がいたら、ぜひご教示ください。 記事では、iframeなどを用いた攻撃について言及されていて、そ

Teratailで、suコマンドでrootログインできないという質問があり、てっきり/etc/pam.d/suまわりの設定かと思いきや、そうではなく、自己解決で説明された原因に一同驚愕ということがありました。 /usr/share/nginx/html に権限を追加したくて、横着して chmod 777 -R /usr とコマンド実行した記憶があります。 CentOS7、suコマンドでrootにログインできない、パスワードは絶対あっているのになぜ？ /usr 以下のパーミッションをすべて777に設定したら、逆に動くべきものが動かなくなる例なのですが、これをやるとセキュリティ上問題であることは言うまでもありません。究極的には、一般ユーザがroot権限とれるかという疑問が出てきますよね。 以前、「chmod 777 -R /usr」が話題になりましたが、これをやると一般権限のユーザーからroo

以下は、特に公表を目的としない個人的な備忘録であるが、公開のメモであるので、もちろん指摘やコメントなどは歓迎する。 PHPの脆弱性 CVE-2018-17082 についてYouTube動画を制作するために、この脆弱性についてあらためて調べているが、Nginxをキャッシュサーバーにしている（リバースPROXYとしてNginxを使っている）場合の挙動についてきちんと調べていなかったので調べ直した。主に以下の記事に関係する。 PHPの脆弱性 CVE-2018-17082 によるキャッシュ汚染についての注意喚起 ブラウザ　<--> リバースプロキシ(Nginx) <--> Apache2 + PHP という構成を前提としている 今までの調査で、Nginxが挟まっている場合攻撃が刺さらないことは判明しているが、なぜ刺さらないかを追っかけきれていなかった。 NginxとApacheの間の通信をキャプチ

Nessusで遊んでいて、「まったくパッチのあたっていないCentOS6.0」を診断してみたら、カーネルパニックで落ちてしまった。こういうことは、たまに（まれに）あって、流石にインターネットからだと滅多にないけど、ローカルから診断するとポートスキャンだけでもサーバーがダウンすることがある。久しぶりに見かけたし、手元の環境では初めてだったので、追いかけることにした。 デーモンが落ちるのではなくカーネルがいきなり落ちることから、NFSかなと思って切り分けたらビンゴだった。NFS単体の脆弱性ではなく（という言い方は変か、とにかくNFS関連のモジュール）、カーネルの脆弱性（どれだろう）のようだ。NFSサーバーではなく、クライアントとしてNFSマウントしているだけで落ちる。 netstat でNFSが開いてるポートを探して $ sudo netstat -anp Active Internet co