削除スクリプト開発スレ
削除スクリプトどうしよう?
今なら削除人さんの意見も取り入れられるかも、
きっと、たぶん、もしかしたら、、 じゃぁ削除人にはスキルごとのアカウント発行すればいいんじゃね。
名前・パス・スキルの3つをセットにして、鯖に格納。
つまり一つのアカウントのパスが漏れても、そのアカウントの権限のことしかできない。 あ、でも>>347をシンプルにすればいいのかな。
ログイン後画面(仮)
─────────────────────
ようこそID○○○さん
key1 .[サブキー ]
key2 .[スキルパス]
鯖 [ ]
板 [ ]
スレッドキー[ ]
─────────────────────
これだけでいいような? 鯖 [ ]
板 [ ]
スレッドキー[ ]
これ分ける理由なんですか
スレッドURL(レス指定含む)でいいでしょ?
勘弁してくださいほんと >>355から先は、既存のUIを流用してもいいし(ここでは書けませんが)。
まあ、サブキーはあってもなくてもいいんですけどね。 >>356
ああ、それでもいいですね。
なんか既存のものに少し囚われすぎていた。
昔はURLがいろいろ変わってたこともあった名残かもしれない。 ユーザーID、パスワード、サブキー、スキルパス
本当に四つも必要なのか? 芋掘り形式と同じでいいと思うのなの。。。@URI指定 新しくアカウントに保有スキル情報を入れるのよねえ?
スキル選択にまでパスワードのような状態にする必要あるのかな。
そりゃ認証が何段階もあればその分セキュアになるとは言えるんだろうけど、
例えばFTPなんて、ID/PWだけで何でもできちゃうわけで、
削除にそんな何段階もやっても、利便性を下げるだけじゃないかな。 実際に作業するのに、1スレ削除するために
URLを3つもの部品に分けて入力なんてやってられませんよ
ログイン画面ならそんなの要らない、
作業画面はURL入力はシンプルに
ログイン画面イメージ
ID[ ]
PASS[ ]
key[ ]
↓入力
作業画面前イメージ
□レス
□透明
□スレッド削除
■スレッド移動 移転先板[ ]
□スレッド停止
□過去ログ チェックボックス入れる
URL[ ]
↓入力
各削除画面 別窓で開く とか ここで議論される方は、せめてItadakiの画面見て欲しい。。。 私も>>361に同意です。
本当に4つもいるのかな? まぁでもItadakiのシステムにはCGI名をいれるところがあるよねえ >>359
サブキーを提案してるのは、一応少しセキュリティーレベルを上げた方が
いいんじゃないか、という意味合いです。
どこかを定期的に変えた方がいいんじゃないか、という。
スキルパスは、人によっては5〜6個以上覚える必要あり(まあメモでもいいんですが)。
それを定期的に変更するのは、スキルの多い人には負担になるかなと。
ユーザーID用パスの変更でもいいんですけど、それだと個別に全部生成
し直しになるので、管理者の方が大変です。
なので、サブキー一つの変更であれば、煩わしさは多少減るかと。
どうしても煩わしいのでしたら引っ込めますが。 >>361
最近じゃID/pass以外に何とかコード(ネットゲならキャラパスとか倉庫パス)入力するのが当たり前になってのに
逆行してないか そんなもん削除人に聞いてくださいよ
スキルパスなるものを設けるのはまぁいいと思いますが、それをCGIのファイル名にして
照合するなんてことはやめてくださいね 現在のツールが、使用者がスクリプト名を入力する必要があるのは、
保有スキル情報がどこにもなく、スクリプト名を知っていることをもって
スキル権限者であるとする運用だからでしょ。 各ツールは後から対応してもらうとして
まずはシンプルに、最低限な機能と
必要なセキュリティを考えればいいのではないかな。 >>369
それはないでしょう。
普通になんかパスワードっぽいのでいいかと。
まあ、今のシステムでも半ば無意識にそれに
近いことをしてるんですけどね。
手入力する人は少ないと思いますが。 >>368
保護の度合いは、保護しようとしているものの価値による。
事業者が保護しようとしているものは、自らの利益。 >>371
そうですね。
まあ後付もできるので(多分サブキーは)、
必要になったら導入でもいいのかもしれません。
ちょっと混乱させたみたいですみません。 >>373
それを言ってしまうと、削除で板崩壊させることも出来るんで
(レス削除だけでも)、安全面はあまり疎かにはできないかと・・・。 ID/PWをユーザが決めるのか、運営者が決めるのか、
という点で前提条件が全く違うんだよね。
アカ窃用の多くは、多くの人は複数サービスで共通のID/PWを
使用しているという現状に乗じて、他サービスのアカ情報を
流用しているから。 >>373
ネットゲならアカハック対策なわけだが
某ネットゲは日本以外で真っ先に導入された
別のネットゲでも日鯖だけは倉庫パス導入されてなかった
それにクレジットガードですら導入してるし
ガラパゴスな国は無関係かwww スキルパスを5,6も覚えるって…まさかスキルごとにパスが違うとか?
そんなにスキルパスは必要なのか?
サブキーにアカウントを紐付けして定期的に発行した方がマシなんじゃ… >>376
IDとパスは、こちらで決めるつもりでいます。 今回みたいにデータが流出したときに
IDとパスが暗号化されていれば、まずは安全と考えていいのかな?
IDとパスだけじゃ不安だから、もう一個必要なのかなって感じなのかな。 それなら、削除人IDに大してスキル毎にパスワードをたくさん当てるとかさ、
例えば俺が削除人ID00001だったとする。
レス削除のパスはABCDEFG、スレストのパスは123456、透明削除ならHIROYUKI、強制dat落ちならKUTIBIRUとする。
格納ファイル上で、パスワードが空になってる場合は権限なしということで。
IDとパスの組を、1人の削除人に対してその人のスキルの数だけ発行するのもいいけど面倒だし。 アカ窃用で決済が行われた場合、事業者のセキュリティが甘ければ、
正規利用者に代金を請求する事はできない、ってのが経済産業省の見解で、
消費者庁はもっと請求撤回に積極的。
誰にも請求できなければ、費用は事業者の持ち出しになるわけで、
それが事業者の損害。
で、2chは。 素の呪文だけだったらはっきり言って使い辛いから使わないわけで
ツールとセットに考えないと dronpoやItadakiは呪文とセットでできたわけじゃないし、
>>371でいいんじゃないかしら。
最初の段階からあれもこれもともりもり詰め込みすぎると、
器ごと破れて収めるところがなくなってしまいそう。 まず、2ちゃん側にツール的な部分を実装するのか
それとも、各ツール作成者にお任せするのか
まずはそれを決めてしまっては?
ツールの話とセキュリティ面の話が入り乱れてるんで。
>371をやってからツール作者が作り始めたほうが穴を見つけやすい
最初からツール前提でやるととんでもない大穴を空けることになる ログイン画面(仮)
─────────────────────
ID .[ ]
PASS .[ ]
─────────────────────
↓
ログイン後画面(仮)
─────────────────────
ようこそID○○○さん
key .[スキルパス]
スレッドURL[ ]
[ O K ] [ログアウト]
─────────────────────
↓
<各処理画面(別画面起動)>
大元のものはこれでいいんじゃないでしょうか。
(サブキーはとりあえず保留)
別画面にするのは、ログイン後画面でURLだけ上書きして
いけば、ある程度の連続処理が出来るように、という感じで。
>>362のようなインターフェースは、ツールの方で
実現していただいた方がいいような気がします。 狙われやすさ。
盗めば金になるとわかっていて、実際に被害も出て、
実際に金を出している顧客からクレームが出ていて、
顧客離れが起きかねなければ、そりゃ強固にもしようってもの。
で、2chは。 不満とかじゃなくてほんっとどうでもいいことなんですが、
でも黙ってられないー
>ようこそID○○○さん
こそばゆいよー ちなみにURL部分は複数行(複数スレッド)対応になっているといいかも。
例えば各処理画面で、ボタンで順に切り替えながら処理できれば、
ツール無しでも、ある程度利便性が向上する気はします。
>>391
まあ、そこは無くてもいいんでスルーしてくださいな。 利便性、安全性、危険性、利益、損害。
大切なのは比較衡量。
危険だから、安全だから、ではなく。 実際作業はツール使ってやるんだから呪文の部分のUIは別に無くてもいいし
現行と同じでいいでしょ?
今回そこが問題なわけじゃないんだし まあ、各要素の評価は人それぞれなのかもしれないけど>>394 >>389
お疲れ様です。ひとつ質問。
スキルパスの情報をユーザー側(ボランティアさん)にも持たせる理由って何でしたっけ?
システム内部に各削除人さんに紐付けた情報を持っていれば良いのでは?
(もちろん、簡単に改竄されたり流出したりしない工夫を内部に持たせますが…) >>397
これも一応パスワードみたいな位置づけで考えてます。
IDとパスが漏れても、その先は起動できないようにという。
いままではスキル毎に呪文が別々になっていたので、
仮にID、パス、呪文が判ったとして、そのスキルしか
少なくとも使えませんでしたね。
入口を一つにすると、全スキル使える人の分が漏れた場合
一気にいろいろ暴れられるので、被害が大きくなる可能性が
高くなります。
そこは必ず入れたいです。 IDとパスが漏れた場合は、スキルパスも漏れていると思うのですが…。
IDとパスが漏れて、スキルパスが漏れない状況というのが、ちょっと想像つきません。すみません。
あとcgiをひとつにするというのは、わたしが思い違いしていました。
以前と同じようにスキル毎のイメージでいたので。ありがとうございます。 >>362
の案に賛成。
最初のログイン認証さえ強固なら、その後は利用できるスキル一覧からチェックボックスとかラジオボタンでスキルを選択しても問題ないと思うんだけどなぁ・・・
一つ削除するだけなのにいくつもいくつもランダム英数文字列を入力しなければいけないのは著しく利便性に欠けるとおもうけど。
利便性と安全性を天秤にかけて、丁度良いころ合いで手を打ってほしい。
実現が可能かは分からないですが提案。
ネットバンキングの認証のように、削除人の端末の情報をある程度記憶しておいて、それ以外の端末からログインしようとした時に限り
秘密の質問の答えが必要とか、ワンタイムパスワードを2ちゃんねるから当該削除人の登録メアドへ送信し、それを受け取った削除人がワンタイムパスを入力するとか。 >>400
IDとPASSを入力してログイン後、スキルPASSと対象レスURLを入力してスキルPASSに対応した削除機能が発動なら
削除人としてのIDとPASS(削除人毎発行)、その時使おうとするスキルのPASS(共通)の3つを入力するだけじゃないですかね
利便性と安全性も丁度良いんじゃないかなと思います スキルの password は共通ではなく、配布時期毎(スキル別)に変えてはどうでしょう >>400
いくらパスワードの仕組みを強固にしたところで、今までよりセキュリティーレベルを下げるって選択肢はないと思うよ。
漏れるのは別にして、鍵一個でクラックされて侵入されたら終わりになってしまう。
勿論強力な錠前にするんだろうけど、絶対開けられない鍵なんてないんだし。
Itadakiもdoronpoも、各呪文を入れるところがあって、それを最初に入れたら保存してくれてただけでしょ。
使い勝手はtoolで対処するレベルの話。
その各toolのpassの保存方法も併せて考える必要あるかもしれないが。 ふとおもったんですが、いつまでの完成を目指すんでしょう?
たとえば今月中にとかなら逆引で今週末までに仕様固めるとかの
線をひけると思うのです。
すでにどこかで発表済だったらごめんなさい。 スキル管理方法が従来とは違うという、前提の違いをまず踏まえてもらわないと。
従来の「スクリプト名」は、第2のパスワードではなく、スキル付与の方法でしかない。
で、そのスキル付与は、システム側で管理するようになった。
この時点で、従来の「スクリプト名」に相当する機能は確保されている。
決して、安全性は低下していない。
その上で、もう一段階の認証を加える意義があるかどうか、だ。 遅ればせながらやって来ましたが、
ここでやったほうがよいでしょうか、
それともよそのほうがいいものでしょうかね。 とりあえずいなむらさんはお止め組の人々に新しくキャップ設定しなおす準備でもしたら
あと作業パスとキャップパスは別にするらしいから、作業パスもかな >>406
赤翡翠さんにメールでいいとおもいます。
おとめのことも念頭に置いてるみたいなので。
あと今ちょうどおいちゃんの雑談スレで
おとめの実装の話が出てるので、
みるといいかもです。 >>408
お話ししてますー
ちょっと落ち着いてからやろうと思ってますよ、
優先順位的に。
赤翡翠さんが念頭においていただいているので、とても助かってます。
雑談スレで、この時点で私ができることはお願いするしか無いような。 >>406>>409
お疲れさまです。
お止めの仕組み自体は雑談スレの方でいいんでしょうかね。
ユーザー管理の話は、キャップスレでやる方向になりそうな予感・・・。
みんなで分担してやれば、まあ何とかなるでしょう。 >>605
やっぱりなかなか難しいんですね・・・。
まあ、LADPは無理だと思ってましたが。 ちょっとUIを修正。(>>362も取り入れてみました)。
ログイン画面(仮)
─────────────────────
ID .[ ]
PASS .[ ]
─────────────────────
↓
ログイン後画面(仮)
─────────────────────
□レス [スキルパス] [OK]
□透明 [スキルパス] [OK]
□スレッド削除 [スキルパス] [OK]
□スレッド移動 [スキルパス] [OK]
□スレッド停止 [スキルパス] [OK]
□過去ログ [スキルパス] [OK]
スレッドURL[ (複数URL入力可) ]
[ログアウト]
─────────────────────
↓
<各処理画面(別画面起動)(仮)>
─────────────────────
[1][2][3] ←複数URL入力時、ボタンorURLで画面切替
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
各処理画面(現行のUIを流用?)
パスの部分は●●●●表示にする形を考えていたので
>>389は起動してみないとどれが起動するか判らないと。
それでは困るので、スキル別に1行にしないと。
スレッド移動は、既存のものから変更。
内容を表示して確認画面で移転先板を入れる方が
要望のあったワンクッションになりますし、誤爆も防げるかなと。
複数URL対応はすぐ実現しないかもしれませんが、とりあえず・・・。
それでIDやパス、スキルパス等を各ローカルPCにどう保存するか?
cookieでもいいのか、それだと危ないのか。 XSSでbeのcookieを抜いてる人がいたらしいので、ちょっと危ないんでしょうね・・・。 >>413
そのuiならbasic認証で良いのかな
人数多いとひどい事なりそうだけど
>>414
後、クッキーにいろいろ書き込むとお腹壊すってばっちゃが言ってました
---
個人で大事にして貰うっきゃないと思いますけどね この期に及んで2ch.netドメインのcookieを利用するのはあり得ない選択肢だと思いますね 水を差すようで悪いんですが
今のスクリプトで脆弱性があったの?
削除人リスト漏れが起きたのは削除スクリプトのせいじゃないんでしょ?
だったら作り変える必要なんてないと思いますが
古い呪文をリネームするだけでOKだと思いますが
なんか雰囲気に流されて無駄な労力しようとしてませんか? IDとパスが平文で保存されていたのも変えなくていい?
サーバが一つやられると情報が漏洩するのもそのまま? >>421
でもソースが公開されたことで、いままで誰も気付かなかった盲点
をみつけられてしまうかもしれないし。。。 >>419
管理がしやすいならBASIC認証でもいいですが
そのあたりはお任せでしょうかね。
まあ、cookie等で残せない事も考えて、>>413で必要事項を
入力しておけば、閉じない限り連続作業ができるように、
というのも想定してました。
ツール等々では、別に設定ファイル等に保存するなどしてもらえば
使い勝手はフォローできるかもしれません。
>>421
元管理人からも号令が出ている専権事項ということで。
ただ、時間は掛かるでしょう。
サザンさんもそんなに時間が取れない状況ですから・・・。
しかし、いつまでも放っておけない所もあるので(要請板など)
つなぎの方法は考え中です(それもサザンさん待ちで)。 (保存無し)cookieに接続元IP(とハッシュ化した何か)も入れておけばいいんじゃない? >>421
削除スクリプトの脆弱性からいろんな勝手cgi実行された。
(削除スクリプトと銘打っておきながら、脆弱性によりどんなスクリプトも実行可能
になっていたと言うオチ)
あ、違うかな。
発端(各cgiの発見)は削除ログからだったけどその後の脆弱性利用は
別のスクリプトだったかも。 削除スクリプトは漏れてなかったよ
漏れたのは何でもできるsikasi.cgi あのsikasi.cgiの認証用データファイル見たけどアカウント5個ぐらいしかなかったから
多分あれは昔の残骸で、今はほとんど使われてなかったものだと思われる(なのに削除もされず実行可能だった) いわゆる最上級な人たち向けのスペシャルなスクリプトでしょ。
これのソースが漏れ、脆弱性を見つけられ、鯖内自由にされて、と。 ログイン情報をどこかに保存しておくなら、前回のログイン時間とホストを、
ログイン後の画面に表示出来ないでしょうかね?
よくインターネットバンキングとかで表示されますが。
(誰かにログイン情報盗まれた場合、気がつくように?)
まあ、無くても構わない話なんですが、本人が見ればすぐ判りますよね。
難しい話でなければ、入っていてもいいのかなと・・・。 メールの返信はいつ来るのでしょう?
もちろんお忙しい事は理解しているのですが、到着していないのでは…と不安になりました。 おいちゃんがお止め組のスクリプトは作ってしまったので、
削除のスクリプトとお止め組統合はナシでお願いします。 >>433
何日何時何分に送ったか教えていただければ調べますよ。
確認作業と整理が終わって、キャップ等の受付が出来るような
状態になって、色々準備できてからになると思います。>返信
ただ、それを受けても削除スクリプトの方がまだ時間が掛かりそう
ですし、その返信はそれが出来てから、になりますね。 >>435
回答ありがとうございました。
お忙しい中。申し訳ありません。
1/8のAM3時頃にcからはじまるソネットメアドから送った者です。
到着していることが分かれば、それで十分ですので…本当に申し訳ありません。 >>437
ありがとうございました。お忙しい中、お手数をおかけしました。 あと決めることってありますかね?
上で接続先登録してとかいう話もありましたけど
そこまでする必要はない・・・気もしますが。
接続環境が複数ある人もいるでしょうし、動的に変わる
場合にはまた面倒ですし、管理の方も大変かなと。
簡単に出来るならいいですけど。
まあ、ログイン時に接続先IPも保存されるとすれば
何かできそうな気もしますが。 接続先なんてコロコロ変わるはずだから
p2みたいにクッキー食べても意味無いかも
それなら有事の場合に備えて自爆パスを個別に作った方が良いかと思う
で、再発行の手順をあらかじめ決めておけばいいのでは? >>432
削除ログが残るんですよね?
いち早く実装するなら、自分の最後の削除記録をTOP画面に
表示するのはいかが
別案として
@自分の削除履歴を照会するcgiを追加するのはどうでしょう
処理後の確認のためにも便利だと思います
Aログインor削除処理したときにメールを飛ばすのはどうでしょう
直近の削除ログは削除人全員が共有できればいいと思うよ
統括さんは全部見れるようにしてさ
怪しい削除とかの抑止になるだろ >>441
私が作るわけではないので何とも言えませんが・・・。
ログインは特定鯖で、削除ログは各鯖に保存するんじゃないかと
思います(そうするかもしれないし、しないかもしれない)。
各鯖に分散保存した場合、いちいちそれを引っ張ってきて検索
するのは効率的じゃないでしょう。
増えたり減ったり入れ替わったりがとにかく激しいですし。
その代わり、ログイン鯖に必ずログイン情報は残ると思いますので
数はあっても検索場所は1カ所だけで済みますから現実的かなと。
メールは結局、鯖のどこかにアドレス情報を持って紐付けしなきゃ
いけなくなりますから、現段階では採用できないかと。 >決めること
辞めたりクビにした人の情報の取り扱い
統括降りたときの情報廃棄のおやくそく パスワードを簡単に変えれるスクリプトは作られてるみたいなので、
キャップも簡単に変えられるスクリプトがまだないのであれば、
いま作って貰えると。 >>444
それはスクリプト云々の話ではないし、統括降りた時の情報廃棄は今までも行ってるんじゃ?
と言うかその程度の「おやくそく」は言われなくても分かっている人が統括になっていると信じたいけど。 ガチでアクティブなメルアド漏れた方
+数年ぶりに戻ってきそうな古参の方もおられると思うので
削除HNを再登録時に選べると良いな・・・ 削除ハンドルは基本自由選択の予定。
変えたいと思ってる人は考えておいてください。 >>443
では私の妄想を書きますよ
削除屋全員にメアド「削除ID@2ch.net」を発行します
そして「削除ID@2ch.net」は各自プロバイダのメアドへ転送設定しておくのです
(いまの仕組みを知りませんが、例えば/etc/aliasesに設定するなど)
CGIはログイン時に「削除ID@2ch.net」にメールを飛ばします
メリットは
・活動休止している人でも不正ログインにすぐ気付く事が出来る
・「削除ID@2ch.net」を連絡用としても使える(公開メアドとするかは別途判断)
・2ch側でプロバイダメアドの生存確認ができる(転送エラーが続く場合)
・今回みたいに削除CGIとID,PASSが漏れても、メアドまでは漏れない
(但し、root権限がクラックされ鯖の設定見られたらアウト)
まあ上記の実装は簡単ですが、政治的なところで実現は難しいとは思いますが。。。
で、話がそれましたが、
>>432の目的は、不正ログインの検知でしょうか?
おまけ程度なら、最終ログイン情報の表示も効果ありと思います
要求レベルがそれ以外だったら、メール送付等も考えても良いのかと思いました >>446
それもこれも含めたセキュリティの話でもあると思うのねなの >>449
そこまでする必要はないし、パーミッションが駄目駄目な2chにメール情報を鯖に置くこと自体が駄目でしょ。
今回のこともあるし、以前rootレベルで見放題になってたこともあるから駄目だな。
削除人・・・というかキャップ餅全員に簡易メール機能みたいなのはあったほうがいいかもしれないけど。
個人的に前回のログイン時刻、ホストぐらいでいいと思う。
不正ログインされたからって個人情報に近いものが漏れなければボラ本人に直接の被害はないからね。 考えるより、動いてしまおう。
問題が、あればそのとき考えよう。
まあ、しゃちょさんならの思考法かな?w 本人確認の進捗はどうなん?>赤翡翠ちゃん
削除スクリプトの見通しも不明だし
まずキャップだけでも配っちゃった方が