slide63の注釈を忘れていたので追加
メルセンヌ・ツイスターと似て非なるアルゴリズムが実装されていたことが発覚して話題の PHP の mt_rand 関数の品質を統計的に検証しました.果たして,PHP の「壊れた」mt_rand は安心して使うことができるのでしょうか……? ちなみに,結論から言うと,PHP の壊れた mt_rand は,(少なくともこのテストの範囲では)本家メルセンヌ・ツイスターと遜色ない品質を持っているようです.ただし,最後に PHP の乱数の別の懸念点についても紹介します. 壊れた mt_rand とは PHP の mt_rand は,ドキュメントによると,有名な乱数生成アルゴリズム「メルセンヌ・ツイスター」を利用して高品質の乱数を生成する関数です.ところが,どうやら一部では知られていたこととして,PHP の mt_rand の実装にはバグがあり,本家メルセンヌ・ツイスターと挙動が一致していませんでした.
Swaggerは、REST APIの仕様とそれに関連するツール群の総称です。REST APIの仕様を定義したJSONファイル(Swagger Spec)を軸に以下のようなツールから構成されています。 Swagger UI - Swagger Spec から動的にAPIドキュメントを生成するツール Swagger Editor - Swagger Specのエディタ Swagger Codegen - Swagger Specからクライアントのコードを生成するツール 最近では、Open API InitiativeがAPIの記述のためにSwaggerを採用して話題になりました。 www.publickey1.jp APIドキュメントのメンテは結構面倒 一般的にAPIの仕様書は、古くはExcel/Wordなどを使ったり、最近ではWikiやMarkdown形式で記述したりなどプロジェクトによって
ファイル名を日本語でダウンロードさせるためには、User-Agentを見てContent-Dispositionヘッダのfilenameの書式や文字コードを書き換える方法1がよく知られていますが、今回はUser-Agentに頼らず日本語ファイル名ダウンロードをクロスブラウザ対応する方法を紹介したいと思います。 概要 User-Agentで分岐してContent-Dispositionヘッダを出すことはしない ブラウザがURLからファイル名を決める仕様を活用する ダウンロードURLのPATH_INFOに日本語ファイル名を入れる ブラウザはファイルを保存するとき、何を参考にしているか? ブラウザがウェブ上のリソースをローカルに保存するとき、必ずファイル名をつけるわけですが、そもそもブラウザは何を参考にして、ファイル名を決めているのでしょうか? 第一に考えられるのが、HTMLなら<title>タ
PHPでMersenne Twister法で擬似乱数を生成する関数のmt_rand()にバグがあり出力がおかしい、という話が流れてきておもしろかったので簡単にまとめておく kusanoさんがmt_rand()の実装に9年以上前から1文字違いでバグがあったことを見つけて、数ヶ月後にマージされる(追記: 正確には、PHP版の実装が他と異なっているのは前から知られていたらしい*1 ) PHPに送った1文字修正するプルリクエストがマージされた🎉 mt_rand()の返す値が元のメルセンヌツイスタと異なっていた。https://t.co/Z5WJhHVyNd— kusanoさん@がんばらない (@kusano_k) February 17, 2016 その後、生成される擬似乱数列が変わってしまうので、後方互換性を壊す変更は議論してからmergeすべきということでrevertされるこの前マージされた
はじめまして。サーバーサイドエンジニアの中野(@Hiraku)です。2015年12月からメルカリで働いています。 2016年1月27日(水)の第98回PHP勉強会@東京にて、composerを速くする取り組みについて発表をしてきました。 composerはPHPにおける実質スタンダードなパッケージマネージャです。 このcomposer、日本で実行すると非常に遅く感じます。この原因は普通ならこう表現すると思います。 githubやpackagistが日本から遠いから composerの実装がよくないから しかし発表ではあえて「光が遅いから」という主張をしました。 一般常識として、光の速さ(真空中で秒速約30万km)はとてつもなく速いものという認識だと思います。しかし一方で、地球や宇宙の規模など極限的な状況に携わる仕事をしている人であれば「全然速くない、むしろ遅い」というのが普通の感覚です。
Joomla! の脆弱性として報告された、リモートから任意のコードを実行可能な脆弱性(CVE-2015-8562)に関する調査レポート 概要 Joomla! に、リモートより任意のコードが実行可能であると報告された脆弱性(CVE-2015-8562)の攻撃コードが発見されました。 この脆弱性は、Joomla! にリモートから入力される PHP オブジェクトの検証処理に欠陥があり、PHP オブジェクトインジェクション攻撃を行うことが可能です。このため、リモートから任意の PHP コードを実行することが可能とされていました。 当初(2015年12月15日)、Joomla! の公式サイトではJoomla! の脆弱性としてこの脆弱性の修正版であるバージョン 3.4.6 をリリースしました。その後、2015年12月21日に、この脆弱性の根本的な原因は、PHP の脆弱性(CVE-2015-6835)で
PHPはよくDISられることがあります。しかし、実際にはほとんどPHPを利用していない人が印象だけでDISってることが多いような気がします。 そこで、PHPがよくDISられている点について、実際どうなのかをPHP未体験者向けに解説していきたいと思います。PHPを触ったことない人でもわかりやすいようにシンプル目な仕様のRubyを例に説明していきたいと思います!( Ruby触ったことなくても、その他のOOP言語を触ったことあれば雰囲気は理解できるように書いています ) DIS例1 / PHPは配列操作がしづらい PHPの配列操作は扱いづらい等とDISる人たちがいます。実際のところどうでしょうか。 以下のような処理を配列への中間変数を用いず行うコードを例に考えてみます。 0. [2,4,6,8,10]という配列を用意して 1. ↑の配列から8以下の数だけを選択した配列を作る 2. ↑の配列から各
Joomla!にコード実行脆弱性(CVE-2015-8562)があり、パッチ公開前から攻撃が観測されていたと話題になっています。 Joomlaに深刻な脆弱性、パッチ公開2日前から攻撃横行 「Joomla!」に再び深刻な脆弱性、3.4.6への速やかなアップデートを推奨 パッチ公開の前に攻撃が始まる状態を「ゼロデイ脆弱性」と言いますが、それでは、この脆弱性のメカニズムはどんなものだろうかと思い、調べてみました。 結論から言えば、この問題はJoomla!側に重大な脆弱性はなく、PHPの既知の脆弱性(CVE-2015-6835)が原因でしたので報告します。 exploitを調べてみる 既にこの問題のexploitは公開されていますが、悪い子が真似するといけないのでURL等は割愛します。以下のページでは攻撃の原理が説明されています。 Vulnerability Details: Joomla! Re
Critical 0-day Remote Command Execution Vulnerability in Joomla Nov 2016 Update: If you need to clean your hacked Joomla site, we have released a new free guide to show you how to identify and remove hacks. Read the Guide! The Joomla security team have just released a new version of Joomla to patch a critical remote command execution vulnerability that affects all versions from 1.5 to 3.4. This is
このエントリは闇PHP Advent Calendar 2015の3日目です。なぜか@do_akiさんによる4日目の記事「ZEND_TICKS と tick 関数」を読んだ後で書いています。 本稿では、あまり日本語での説明を見たことがないPHPのインターン化文字列(interned strings)について紹介します。 文字列のインターン化とは 文字列のインターン化というのは多くのプログラミング言語で採用されているテクニックで、同じ不変文字列がプログラム中に何度も登場するような場合に、毎回文字列をコピーするのではなく同じ文字列を共有することで実行時間やメモリ消費量などを有利にするようなものです。Wikipediaの「String interning」なども参照してください。 internというのは軍などで使われる単語で、抑留というのが日本語で一番近い単語だと思いますが、どうもピンとこないの
脆弱性スキャンツールのテストあるいは脆弱性内容の学習を目的として、意図的に脆弱性が作り込まれたWebアプリケーションをいろいろ調べた結果のメモ。 Badstore Badstore: 1.2.3 ~ VulnHub Last update: 2004-02-24 (1.2.3) この手のアプリケーションの元祖であり、現在はメンテナンスされていない。 ショッピングカートを模したつくりになっている。 また、ISOイメージとして配布されている。 BodgeIt Store (The image is taken from The BodgeIt Store Part 1 - InfoSec Resources) bodgeit - The BodgeIt Store is a vulnerable web application suitable for pen testing - Google
昨日11/22(日)に第六回闇PHP勉強会が開催されました。PHPの勉強会なのにPHPのコードが全部で10行も登場しないという毎度おなじみの展開でしたが、たくさんの方にご参加頂きました。本当にありがとうございました。 では、発表を順に紹介します。 @hnw 「OPcacheの新機能ファイルベースキャッシュの内部実装を読んでみた」 まずは僕の発表からでした。PHP7からの新機能であるOPcacheのファイルベースキャッシュについてソースコードを交えて仕組みを紹介しました。本機能について、個人的には若干ネガティブに見ていますが、今後「こういう状況では確かに便利だ」という事例が出てくれば判断も変わると思います。 @noldorinfoさん「SQLite2と3のエスケープ関数の違いとその対策」 SQLite3のエスケープ関数がSQLite2のものと実装が変わっており、バイナリアンセーフになっていて
2. 2 Survey of object serialization vulnerabilities Example exploitation − Sample Apps − Novel Vectors − New Tools Mitigation techniques Talk Goals *Did our best to find previous research and give credit/references. Please let us know if we missed any. 3. 3 snapshots one or more “live”, in-memory objects into a flat, serial stream of data that can be stored or transmitted for reconstitution and us
4年前にHashDos(Hash Collision Attack)に関する効率的な攻撃方法が28C3にて公開され、PHPを含む主要言語がこの攻撃の影響を受けるため対策を実施しました。しかし、PHP以外の言語が、ハッシュが衝突するデータを予測困難にする対策をとったのに対して、PHPは、GET/POST/COOKIE等の入力データの個数を制限するという対症療法を実施したため、PHPにはHashDosに対する攻撃経路がまだ残っているということは、一部の技術者には知られていました。例えば、以下の様なつぶやきにも見ることができます。 だって、 hashdos 脆弱性の時、 Python とかの言語が、外部入力をハッシュに入れるときに衝突を狙えないように対策したのに、phpだけPOST処理で対策したからね? json を受け取るような口もってるphpアプリのほとんどがhashdos残ってるんじゃない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く