【浴衣の君は・・・】　●サーバとまります。

このへんか、

http://d.hatena.ne.jp/i_ogi/20100217/stream

これもよく使うHTTPとHTTPS。

ちなみにPOSTを利用したい場合や、ヘッダをつけてリクエストしたい場合は、fopen や file_get_contents といった関数には、contextというオプション引数があり、そこに stream_context_create関数で、メソッドやヘッダを指定することで、PEARやcurlを利用することなく対応できます。

このストリームは読み込みのみに対応しているため、例えば、file_put_contentsでファイルを作成したりすることはできません。

http://www.phppro.jp/word/POST

PHPでは$_POST変数を使うことで、POSTメソッドで送信されたデータを取得できる。

て

書きこめねーぞ！！

どれどれ

書けたぞこのやろー

とりあえずGETは拒否したほうがいいんじゃない？
なんかGETでXSSとか結構見た気がする

穴を作っちゃだめ

それをするにはPOSTで滞りなく受け取れるようになってからだ・・・

別にGETがダメなわけじゃない
受け取ったデータを適切に処理すれば良い

GETは昔から使えたぞ
新参か？

GETだとリファラー漏れする危険もあるから非推奨だろ

同意

<?php
echo $_SERVER['REQUEST_METHOD'];
?>

話題になった事故から得た知識ですか。
ウェブブラウズしてるわけでなく、専ブラが内部的に呼び出すAPIなんだから
XSSもリファラも関係ないですよ。

ついでに、XSSはGET/POST関係なく発生する。
入力値をそのまま出力することに起因する脆弱性だから。

確かにtext/plainだと$_POSTに反映されないねぇ。
設定でなんとかならないのかな。
Perlっぽくこんな感じならいけた。

$stdin = file_get_contents("php://input");
$parm = preg_split("/&/", $stdin);
foreach ($parm as $p) {
$a = preg_split("/=/", $p);
$post[$a[0]] = $a[1];
}

平日の場合はできるだけ昼間に実験やったほうが混乱が少ないのでは？

昼間の場合でもネット廃人が粘着しに来ますから邪魔なレス数は結局同じくらいです
要はいつやってもどちらでも同じこってす

>>799
パスワードに&入ってるとマズイけどそんな奴たぶん居ないだろうな

パスワードは半角英数だけ
（いまのところ、だけど）

file_get_contents("php://input") てのでどうかしら

------ サンプル ------
<?php
header('content-type:text/plain;charset=UTF-8');
var_dump(getallheaders());
echo "↓\$_POSTは空\n";
var_dump($_POST);
echo "↓これで取ってあとは自前で\n";
var_dump(file_get_contents("php://input"));
?>
------ 出力 ------
array(6) {
["Accept"]=>
string(3) "*/*"
["Content-Type"]=>
string(10) "text/plain"
["User-Agent"]=>
string(10) "DOLIB/1.00"
["X-2ch-Ua"]=>
string(12) "pokotan/0.01"
["Content-Length"]=>
string(2) "30"
["Host"]=>
string(15) "www.example.net"
}
↓$_POSTは空
array(0) {
}
↓これで取ってあとは自前で
string(30) "[email protected]&PW=pasuwaado"

>>804
私だったら即それ使います

$_POSTやらなんだらは難しすぎる

PHPならTUBO君が詳しいんじゃないかな

つボイノリオ？

俺のは POST してると思うけど GET への対応もお願いします>>作業してるボケ

Cで作り直すのが一番早いんじゃないの？

>>806
つぼくんはコスプレするのに忙しいです(ぉ

ぜんぜんリロードしてなかった
すでにガネさんが紹介してました

>>808
GETは動作に問題なさそう

http://pc8.2ch.net/test/read.cgi/php/1127581425/

ふっるｗ

http://pc8.2ch.net/test/read.cgi/php/1127581425/180-


http://pc8.2ch.net/test/read.cgi/php/1127581425/183
PHPで受け取るならname=value&name1=value1の形式で
Content-type: application/x-www-urlencoded
がないと$_POSTには入らない
で$_POSTになければ$HTTP_RAW_POST_DATAを見てみたらあるかも

>>809
それじゃ　すぐ出来ちゃうじゃん

大人しく標準入力から読むしかないんじゃ・・・　

>>816
そんなような感じなんでしょねぇ
text/plain でも$_POSTに入る方法はなてかなぁとおもってくぐっていたけど
なかなかないもんですな

$HTTP_RAW_POST_DATA と php://input のどちらを使っても text/plain の POSTデータを
取得できるけど、php://input のほうがちょっと良いのかも

http://www.php.net/manual/ja/wrappers.php.php
> php://input は、POST の生データの読み込みを 許可します。これは $HTTP_RAW_POST_DATA に比べて
> メモリ消費量が少なく、特別な php.ini ディレクティブを設定する 必要がありません。
> php://input は、 enctype="multipart/form-data" に対しては 使用できません。

ざっと読んでみますた。

・今までのCバージョンでは、

Content-type: text/plain

とかで HTTP POST してくる(誤った仕様の)専用ブラウザからのリクエストも
偶然、正しく受け付けられていた

のが、

・今回のPHPバージョンでは、きちんと、

Content-type: application/x-www-form-urlencoded

で HTTP POST してくる専用ブラウザのリクエストしか、
受け付けられなくなった

ということなのかしら。

たぶん　そんな感じ

ただし「誤った仕様」とは思っていないですが、
仕様書に書いてないし・・・　←　作った人が無知だっただけだと思いますが、

「読んでみた」は、このスレの流れで。>>819

>>820
なるほどです。

で、それをPHP側で回避できる方法がないか、模索中と。

.htaccess のrewriteとかで　text/plain を書き換えちゃったりもできるのかしら?

A Boneで書き込めねーぞ！何とかしろよチンカス

面白いのは・・・・・
qb6のbbs.cgiは(新)ですが、すでに普通のテストはほとんどなく
破る気まんまんなアクセスばかりと、
5年は持たせたいんですけどねぇ

>>825
チャレンジャーさんがごろごろいらっしゃる、ということですか。

むしろ application/x-www-form-urlencoded で送るのが間違いだったからね。
その方式で送るとは定めていないし、
実際URLエンコードして送るとエラーだし。

チャレンジさんを規制したほうが早そう

焼くには焼く理由が必要なのねん

俺が自前ツールでやってたときは、Content-type はヘッダ自体送っていなかった。
そういう専ブラもあるんじゃないかな。

チャレンジはおやめくださいニヤリとか

認証サーバにもバーボンみたいなのをいれようかなと思ったけど
破られたり破ったりが面白いですからねぇ

いつだかみたいに、ハニーポットで以下略とか。

>>832
認証バーボン入れると糞な実装してる専ブラが死んじゃうからやめて！

>>834
そっちの意味ではすぐにでも入れたい。
なんの為にセッションID方式にしたのかと、

この際仕様はかっちりしたほうがいいんじゃないかなあとか

同一内容の連続投稿は禁止されてます

(板内)

とか

こまめにログイン、ログアウトしてゴメンナサイ

何をどうやっても突破されるのは仕方ないよね
セッションIDって本来はその文字列自体に意味がない整理券のはずだけど、
２ちゃんねるの膨大な●書き込について一々セッションID<->ユーザー情報
の問い合わせをしていたらリソースが足りなくなるので、
セッションID自体に暗号化した情報を載せてサーバー側の計算だけで
元のユーザー情報を復元しているのだから、結局その規則性が解読されたらアウト

しかもセッションIDは無制限に発行しているので
なおさら規則性を見つけられやすいという状態

仕様自体はかっちりしていると思うよ。
ただ、一般的なウェブアクセスとは異なる仕様だから、
各種言語の標準的な動作では対応できないってだけで。

そうなんですよね、
でも被害(?)は書き込めたり読めたりするだけですからねぇ

●のメンテもいいけど、安易に長期間ドメインレベルで全体規制かける今の体制もどうにかしてくれよん
UCOMの全体規制が三ヶ月目突入で巻き込まれユーザーが涙目
この状態でさらに7重の規制要請があがってきてるとか・・・もうね・・・今年書き込み無理じゃね？
今の規制の仕方じゃ、巻き込み被害ばかりで荒らし本人には効果出てないと思うよ正直

だから普通に●買えって言ってるんだろｗ
いやだよ

今日はもうねむーなのでそろそろ離脱ですが、

; Always populate the $HTTP_RAW_POST_DATA variable. PHP's default behavior is
; to disable this feature.
; http://php.net/always-populate-raw-post-data
always_populate_raw_post_data = On

これを認証サーバの php.ini に入れてみるとか。

もし的はずれだったらごめんなさい。

>>759,761,819

ヘッダにContent-type: application/x-www-urlencodedを追加したらfuten2.cgiでlogon OK、
qb6にも●が書けるようになりました。ということでこっちの問題でした。
ついでにログオンに失敗したJaneViewはDDOSアタッカーになってしまうようです。
すいません。

どもども

要はSIDの暗号強度の問題。

SIDの形式を
<●IDの暗号化(a)><発行日時(b)><a+b+秘密鍵 のハッシュ>
とかにするんじゃだめなん？

a は●規制に使っている奴を、futenで作成するようにする。
現状の生IDを暗号化して2chに送るのは、2chはセッション確認時に復号して
生IDを得られることになるので。
（●の運営者は2chとは別の会社）

bは現状と同様。

2chはセッション確認時に、
・b で有効期限を確認
・a+b+秘密鍵 のハッシュを作成し、SID内のハッシュと照合
・投稿記録には a を保存
とする

a と b はSID上で生文字列だから偽造できるけど、秘密鍵を割らない限り、
ハッシュ照合で弾かれる。
また、秘密鍵はいつでも変更できる。

問題はハッシュ作成のコスト？

暗号の強弱は時間だとおもう
ただそれだけなんだ

いくらいろいろ考えても　10年持ったやつと5年始か持たなかったやつと比較すると
10年持ったほうがエライだけなんじゃないかな、きっと

現状

futen.cgi
Content-type: application/x-www-urlencodedの有無にかかわらずID,PASSWORDを生で送信するとログオン可、URLEncodeするとログオン不可。

futen2.cgi
・Content-type: application/x-www-urlencodedがないとID,PASSWORDは生でもURLEncodeでもログオン不可
・Content-type: application/x-www-urlencodedがあるとID,PASSWORDは生でもURLEncodeでもログオン可

解読しなくても推測で中身を変えられちゃう独自の暗号方式よりは、
世界で研磨された暗号方式やハッシュ方式の方が長持ち。

>>849
どうもありがとう

>>850
楽しみとかは?

ないよ

ということは、動機がなくなっちゃうなぁ

100%全てが娯楽である必要はないと思うけどね。
土台くらいは無機質に作っても良いんじゃないの。
その上で楽しく遊べれば。

「規制体制どうにかしてくれよん」とか言ってる俺が言うのもなんだがー
何故、正常に通るヘッダーとエラーになるヘッダーの違いの洗い出し検証の話しから
セキュリティーの話しになってるんだ？ｗ

話題が2つあるだけでしょ。

たまに破られるくらいがきっといいんじゃないかなぁ>>854
ただで宣伝してくれているようだし

>>855
そんな深夜がいい感じ

御意ｗ

こうして運用の夜は更けていくのでありました・・

これから5次会よー

>>823
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^POST$
RewriteCond %{HTTP:Content-Type} !application/x-www-form-urlencoded
RewriteCond %{HTTP:Content-Type} !text/plain
RewriteRule .* - [F]
RequestHeader set Content-Type application/x-www-form-urlencoded

1. リクエストメソッドが POST
2. Content-Type が application/x-www-form-urlencoded じゃない
3. Content-Type が text/plain じゃない

1〜3をすべて満たしたら 403 Forbidden で終了
GET は1を満たさないのでスルー
Content-Type: application/x-www-form-urlencoded は2を満たさないのでスルー
Content-Type: text/plain は3を満たさないのでスルー
スルーしてきたら Content-Type: application/x-www-form-urlencoded をセットしちゃう

このほかにRequestHeader で環境変数による条件判断をさせる手もあるみたい

403はアクセス拒否
この場合は400(Bad Request)

>>861
書き換えるまでは出来ないんですかね、
rewriteというぐらいですから、

と、ここまでの話を踏まえて、 futen2.cgiを text/plain等で問い合わせても
正しくセッションIDを返すように改修中。

>>862
400を返すフラグがあれば……

>>863
RequestHeader set は、当該のリクエストヘッダがなければ付加し、あれば書き換えます

やっぱfuten2の改修がベターすね
楽しみ楽しみ

やはりmainしか無いソースなんだろうか？ｗ

そんなもんだと思う
ID,PWが正しいか、セッションIDを発行するだけだし

ギコナビも >>849 と同じで、futen2.cgiには、ヘッダを足さないとエラーになりました。

基本的な方針としては、futen2.cgiを直して、アプリ側は修正しないでいいんでしょうか？

その方向だけど、将来のことを考えると直してくださいー

今　futen2.cgi 修正しているから
出来上がったら報告しますんでまた実験してみてくださいー

>>861,864
＞ RequestHeader set は、当該のリクエストヘッダがなければ付加し、あれば書き換えます

RequestHeader setだけにして毎回強制書き換えじゃ駄目？

どうせ入力データのチェックは必ずやるんだから、ヘッダのチェックまでは
無くても良いんじゃ無いかなあと。

futen2.cgi 改修しましたー
>>849 あたりどうなったかテストしていただけるとありがたいですー

17:00 頃に切り替えテストまたやってみるか!
まだ過去ログは読めないけど、今晩やるかぁ

と思ったけど、暇になったから早速やるだ

認証サーバ(新)にします。　→　これからログインした人は qb6しか書けなくなる。

>>872
なんということでしょう

うまく行ったら全サーバでテストする
失敗したらまた撤退

これって例のモペキチツール系の奴も使えなくなるでおｋ？

書けない

beには書けなかった。ここなら書けるのか

まだかに?

勘違いbeにも書けた

>>875
この先、10年は通用するもん作りたいらしいから、そうなんだろ

ちょっと失敗、
ちょっとごにょってくる

ここに書けたら掛けるでしょ。qb5だし
んでこれでモペキチ●突破対策したってこと？

P2で●使えるよう戻して下さい・・・お願いします。

テスト

ギコナビは駄目ですね。
>>867 と状況変わらず、ヘッダ足さないとエラーになっちゃいます。

うにゅ

---

Monazilla/1.00 (JaneStyle/3.40)

>>885
現在の futen2.cgi でどうでしょうか?

>>861
これをやってみよう!

futen2.cgiによるセッションID取得テスト
POST、text/plain　→失敗 pppppppp...
POST、application/x-www-form-urlencoded　→成功 新セッションID
GET →成功 新セッションID

もう専ブラに修正頼んだ方が早い気がしないでもない

RewriteEngine on
RequestHeader set Content-Type application/x-www-form-urlencoded

を試してみよう

てすと

まだPOST、text/plainだと失敗するぞー

>>889
逃げちゃダメだ

>>893
することなくなっちゃうもんねぇ

公式の専用ブラウザ作ればすべて解決

>>889
「DOLIB 2.0では、POSTかつapplication/x-www-form-urlencodedでの送信が必須となります」
とかでもいいと思うけど、おいちゃんが互換性にこだわってるみたいなので

だよねえ
確かに互換性は必要だけど・・・

ちなみにまだPOST、text/plainでは成功しない

>>895
禁断の壷の悪夢再びか、それもいいな。

ちとまってね、いろいろ講義しながらすすめているから

入れてるけどどうだろ

>>895
つ　ｐ２

こっちの動きに関係なく専ぶらはどんどん書き換えて行ってね。
application/x-www-form-urlencoded

お？
POST、text/plainで成功したみたい

まだ駄目でした。

とりあえず、人柱版で修正をリリースしておきました。

futen2.cgi、POST、text/plainで新セッションID取得成功

おお

>>904 >>906
おっおっ　

>>905
ありがとう

>905 ごめんなさい。
今やったら、POSTでヘッダなしでもいけました。

qb6に、futen2.cgi、POST、text/plainで取得したセッションIDで書けました。

futen2.cgiをfuten.cgiに移して、新●のbbs.cgi、offlaw.cgiを全鯖に配布する段階に進む？

全鯖配布ですか
これでモペキチツール使用も終わりですね

そいやqb6のofflaw.cgiと新セッションIDで過去ログが取れるかは試してないけど
そもそもqb6のofflaw.cgiって動かないし

よーし　やってみよう!!
認証サーバ(新)にします

>>910
offlaw.cgi は今晩徹夜で書くー
bba.cgiはまずqb6でそして全サーバへ
準備してくるー

ツール終わったかどうかのテストをツールで

futen.cgi、POST、text/plainで新セッションIDがとれることを確認。

よく考えたら俺場違いだった

いいよいいよー

出遅れた

>>870
確かに。それでいいすね

>>890
RewriteEngine on の行はたぶん不要です
RequestHeader は mod_headers という mod_rewrite とは別のモジュールのディレクティブです

全サーバのbbs.cgi(新)いくー

>>913
徹夜のコーディングはだんだん脳が溶けて楽しくなってくるから素敵

ではqb5の運用情報板でのテストに移ります。

bbs.cgi(新)@qb5 セッションID(新)

どーだ

やっと参加

どうよ？

書けるかな？

---

Monazilla/1.00 kage/0.99.1.1212 (0)

原理的には、一般の専用ブラウザで試験ができる段階に進んだのか？
ところで、●の規制の互換性ってどうなってる？
クリアして最初から？それともこのまま行ける？

ん？

どきどき

---

Monazilla/1.00 (JaneStyle/2.83)

一応昨日ログイン弾かれた組

---

Monazilla/1.00 Live2ch/1.19

>>926
やっているうちに実態がわかってくると思うだー
目論見としては・・・　内緒(上位互換は目指した)

test

うん、POST、text/plainで取得した新セッションIDで、qb5に問題なく書けるようです

いまのところ順調

ただし offlaw.cgi(新)はまだない

こっちもテスト

---

Monazilla/1.00 BB2C/1.0

使えなくなっちまった

再ログインエラー、やっと消えた。

てｓ」

じゃぁ全鯖にbbs.cgi(新)を配布？
ってことはofflaw.cgi(新)ができるまで過去ログは見れないということに・・・

書けるかな

モペキチのバグ利用Javascriptタイプの方でてｓｔ

書けなくなった(´･ω･｀)

jane2.78書き込めないです

あ

あ

qb5,qb6,takeshima は移行済み
他のサーバはふらふらする予感、時間がたてば(20min?) 全部(新)に移行するはず

てすと

あ・・・be出しちゃった・・・って完全復活してたのね
ちゃんと使えなくなってるね。ちきちーた乙

てそ

---

Monazilla/1.00 (P2/p2.2ch.net; p2-client-ip: 111.102.131.75; p2-user: 719581)

●とまったの？

まぁ今晩だけなら我慢するべかね

のわーん
書けないないよぅ兄貴ー

>>945
takeshima？

これでどうだ

てｓ

---

Monazilla/1.00 (JaneStyle/3.40)

なにもdion軍規制の時にやらんでも…
何事かと思ったわ

bank経由はエラーになります

---

Monazilla/1.00 BB2C/1.0

tsushimaかけた

書けない人は専ブラも書いてね

あ、いけたw

---

Monazilla/1.00 BB2C/1.0

live2chからですお

アフィスタイルだけど●つかえなくなった

test
janestyle3.30

書けませんよ

規制は仕方ないよね

---

Monazilla/1.00 Live2ch/1.19

3.40むりだな
これを気に乗り換えるか

Jane Style 3.40　無理

てす

古い●IDをbbs.cgi(新)に投げると、
「再度ログインしてね」とか出ないで、●無効のまま書き込みがされる（○になる）んだが・・・
意図した動作？
多分「再度ログインしてね」を出せば専用ブラウザが自動でログインし直すと思うから
そっちのほうが・・・

書き込めなくなった

Style1.25も無理でした

ログインしなおしたら書けるかも報告

ジェンスタ3.4

Jane系統はセッションIDを使いまわすからブラウザ再起動がいいかもね

てす

Jane Style3.40βだけどいけるよ。
一度再起動してログインしてみたらいけない？

どうかな

>>965-966
ログインしなおして一応ブラウザ再起動したらでけた

---

Monazilla/1.00 (JaneStyle/3.40)

どれどれ

---

Monazilla/1.00 (JaneView/0.1.12.1)

tesu

お、再ログインで書けた

>>971
まじだ
3.40だけどできた

さっきエラー出たからログインしなおした

どうせ全サーバ規制だし、書ける＝●が有効って事だけど

大丈夫かな。

再ログインしたらいけた
ν速でクソスレたてたから焼かれたかと思った

無限生成はおわったのか

ログインし直すの忘れてた

---

Monazilla/1.00 (JaneView/0.1.12.1)

ログインできない

Style3.03
再起動でokでした

書けるか？

みんな●使えなかったのか・・・
焦ってｐ２入れちゃったよ

Jane Style3.32も再起動して問題なし

>>984
おれもだ

おてす

次スレ
【浴衣の君は・・・】　●サーバとまります。 Part2
http://qb5.2ch.net/test/read.cgi/operate/1278751344/

再起動したらいけた1.25

ギコ

---

Monazilla/1.00 gikoNavi/beta62/1.62.0.804

>>990
焦りすぎだろｗ

てす

がんばれ

記念

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。