削除スクリプト開発スレ
削除スクリプトどうしよう?
今なら削除人さんの意見も取り入れられるかも、
きっと、たぶん、もしかしたら、、 メールアドレスとかですかね。
ちょっと行ってきます。もう拡散しまくってますけど。 個人的にはIPが出ない場所の方がうれしいなあと。
このIPアドレスから何かやられたら面倒ですしね。 >>295
いつからメルアドが削除対象になったんですか? >>295
赤なんちゃらさんの熱意は理解で決めるけど、やめておきなさい。努力の無駄です。
とうの前に検索エンジン等のキャッシュとして収集されているし、多くの人のローカルに保存されている。
インターネットにおいては、一度でも流出したら情報の削除は不可能なのですよ。
赤なんちゃらさんには別のもっと有意義なことに注力してもらいたいし、
今やる事がないのなら一息おいて、やることが来たときのために力をためて欲しい。
>>307
× 熱意は理解で決めるけど
○ 熱意は理解できるけど
このままだと2chのログに永遠に残っちゃうけどね。
削除しておけば1年後に収集することは再うpされない限り難しくなってるでしょう。
というかそれ行っちゃ削除の意味がない。 メルアドってだけで削除していいの?
削除人は自分の個人情報が流れたら削除GLを無視して自分のためだけに削除権を使用していいの? >>305,310
このようなメールアドレス晒しは重要削除対象です
>>307
要請で多くの依頼が対応待ちしているなかで優先して処理する理由はなんですか >>309
「現行サーバのdatは汚染されている可能性があるから全て放棄し、新サーバには持って行かない」
という方針(のはず)だから、その心配は不要かと。
アンカー間違った>311
>>312
datは新しい過去ログサーバ行きじゃなくて破棄? >>313
368 名前: ◆A/T2/75/82 投稿日:2011/01/07(金) 19:36:12 発信元:114.160.23.32 0
さてさて ここまで来た
ちと疲れたが、まぁ動いているようじゃ。
今やっていること
A) まったく新しく2ちゃんねるを作り直し @hato
B) 全てのサーバは捨てて(datも)新しいサーバに入れ替え
の二本立てです。
次は何をしなきゃかな?
・キャップ?
・芋掘り&規制?
http://dso.2ch.net/test/read.cgi/sakhalin/1294323418/368
>>313
危険すぎて持って行けるわけないかと。
誰がどんなコードを仕込んでいるかわからない。検証すら出来ない。
赤翡翠さんが、どういう立場の人かは、実はよーしらんけど。
緊急時でもあるし、誰かに号令かけて旗振ってもらわなきゃいけないんだから
とりあえず助けてみたらどうだろう?
責任は、どうせ姿を現さないパケモンだかどうやらさんだかに押しつけときゃいいんだから。 logsoku.comやunkar.orgには残ってるけどそのうち消えるのかな >>291
念のため。私は謝罪を求める意図で書いたのではなく>>292さんの仰るような意図で書きました。 ここはスレタイ通り削除スクリプトを開発するスレ。
キャップ開発は別スレでやってる。
あと、謝罪だとか責任だとか開発と直接関係ない物は別スレでゆっくりと議論するなりなんなりした方がいいと思われ。 とりあえずぼやき。
削除スクリプトをどこに置いても漏洩する可能性が消えるわけじゃないので、
別httpdを立てるほどのものじゃないと思うけどなぁ。
入り口(UI&API)を1つのサーバにまとめるならありかも。
各サーバの削除スクリプトは入り口からのみ受け入れるようにして。
アカウントの管理はパスワードのハッシュ値を保存するとして、
スキル検査も認証に組み込んでおきたいねぇ。
認証情報はpublic_htmlの外に置くか別の仕組みを使って
認証できるとよさげかも。
機能強化については従来通りツールで対応ですかねぇ。
無いと困るものを除いて。 >>276
>・削除人専用窓口へのアクセスの仕方 testの下に置いておいていいのか?
既出だが、別のディレクトリに分けるのが良いに1票
URLがバレた時は、ディレクトリ名を変更するだけでOK
Basic認証するにもディレクトリ丸ごとのほうが簡単で設定漏れもないし
>>294
タイトル:■YouTubeが流行ってるらしいですよの巻■
======2==C==H======================================================
2ちゃんねるのお勧めな話題と
ネットでの面白い出来事を配送したいと思ってます。。。
===============================読者数: 133,805 人 発行日:2006/05/31
最後に受け取ったのは2006/05/31だね
その後受信用のメールアドレスが失効したので届いてないですけどね 最終発効日は2006/12/11のようですが現在は休刊中のもようです >>274-276
遅ればせながら、まとめありがとうございます。
だいたいの要望等は箇条書きにしていただいた感じでいいですかね。
他にあれば追加ということで。
>>323
お疲れさまです。
流れ的には、そういう感じになっていくんでしょうね。
パスについては、暗号化など技術的なところはお任せするとして、
各IDのパスの他にもう一つ、定期的に変更するパス(サブパス)を
入れた方がいいかなと思っていますがどうでしょう?
(一応、既に書いたことの延長になりますが)
セキュリティーレベルの高い企業では、数ヶ月毎にパスの変更を要求
されたりしますが、各人のものを個別に変更する仕組みだと、使う方も
少々大変です(もちろん仕組みを作る方も、管理する方も)。
必要なときに現在のサブパスを確認し、また管理側も個別に漏れた
可能性が否定できなければ、その都度サブパスを変更すると。
(アカウントが特定できればそれだけ止めれば済みますが、
使われないと判らない場合もありますので)
漏れの可能性がなければ、半年か1年ごとの更新でいいと思いますが。 >>303含め、ご協力ありがとうございました。
まだ続くとは思いますが、出来ることをやっていきたいと思います。
とりあえず全部にメールという話は、誰から送るべきかという点で、
すでにがるさんが代わりに詳しく説明してくれています(ありがとう
ございます)。
同様のことを言いたかったのですが、言葉足らずですみません。
私の方から、何らかのアナウンスはした方がいいのではという提案は
代理人さん含めてしてあります。
それに対してどうリアクションするのか、それは現段階では判りませんが・・・。
URLは、色んな所に送信されたり、記録されたりするので、
GETは禁止して、POSTでID・PWを送信するようにー 偽装メール見破る自信ないしメール送ってこられても対応できませんわ >>331
こことかで聞いても良いし、公開できない内容ならメールで聞いても
良いんじゃないですかね?
他人には侵入出来ない(と説明のあった)メアドあるんだから。 >328
変更したサブパスを通知することを考えると、
かえって手間の方が増えるだけかと。
それにサブパスを作るよりも、
呪文を変更したほうが楽だと思うなぁ。 削除サブパス通達用の自動返信アドレスを作って
削除人がソコへカラメル送ると自動でパスが返信されるようにすればいいじゃん
1年間サブパス問い合わせしなかったメアドを自動でリストから削除すれば
現役さんの生存確認にも使えるし >>333
サブパスは一斉送信ではなく、連絡スレ等で告知して、
問い合わせして貰うのでいいと思うんです。
なので、基本的にはそう変えないつもり。
(ちなみに返信する手間は考えなくていいです。
いまやってる作業より遙かに楽だし(汗))。
呪文を変えて連絡する方が大変な気がしたり・・・。
定期的に変えるわけにもいかないでしょうし。
(中身の改修も伴うなら)
このあたりは使う削除人さん的にはどうでしょう?
まあ、ユーザー管理から削除スクリプトに行くところの
パスみたいなイメージで考えたんですが、UIがどうなるか
わからないので、無理は言いません。 赤翡翠さんのイメージを実際に導入しようとするとこんな感じなのかなあ
▼削除プログラム起動時
1. 削除フロント(qb7のある鯖)でキャップパスとサブキーを入力
2. キャップパスの照合を実施
3. 照合が通ったらサブキー(+キャップパス)で二次キー再照合実施
4. キャップパス+サブキー紐付けDBで照合実施
5. 実施結果が真なら削除スクリプトの起動を許可
---
▼サブキー管理
1. 削除フロントからサブキーの紐付け登録を実施
2. 二次キーを生成して照合用DBへ登録
※このとき、登録日時を記録
i. 二次キーを有限(1〜3ヶ月)で使用不能とする
ii. 二次キー期限切れの場合は、元キー+新キー+キャップパス+魔法の呪文で登録申請実施
(再登録申請時、管理者が許可をして実登録が実施されるようにすると、人的確認が実施可能)
---
<蛇足>
▼防御策
1. n回以上の不正なキーでアタックが実施された時
kickリスト+バーボン送り+リストアップ実施
▼自爆機能
1. 急遽止めたい場合に、管理者権限でポチッとなで全停止が可能になるようにする
※システムを動かす為のマスターキーを即破棄して認証されないようにする
</蛇足> キャップパスを認証に使うのは不都合があるのでやめてください。。。 この際良く分からん状況は全部破棄して
管理上名前と権限を一対一にしておくべきだと思いますけどね キャップパスを認証に使わなくとも削除アカウント(ID)でいいでしょ 幸せサーバーの誰かみたいに、名前欄に入れたりとかしてうっかりキャップキーを漏らしたりしちゃう可能性がある
そうするといろいろと不都合でしょ キャップパスを認証に使っていたお止め組の方法がまずいからという理由で
削除と同一の方法で認証するようにという議論で進んでいたのに
ここで削除がキャップパスで認証するという事になると、まずいでしょう。 >>336
えーと、一つだけ言えばキャップでの認証はしません。
キャップは漏れやすいのと、漏れても気がつかないこともあるので。
頻繁に変更する可能性もあるから、それを認証に使わない方がいいです。 その為のサブキーだと思ったんですけどねえ。
片方漏れても大丈夫、的な >>343
> 頻繁に変更する可能性もあるから
メインキーもサブキーも更新されるなら、それこそ防御性が上がるんだと思うんですが、
その辺はどうなんでしょうか。
---
変更出来てしまうものは、認証に用いるべきではないという事ですかね
となると、定期的に変えられるサブキーを要するなんてのはそこから反してしまいますかね というか、>>212のツリーを参考にイメージしていたのです。
なので、>>336を私のイメージで直すとこんな感じです(あくまで参考)
▼ユーザーログイン
1. 削除フロント(qb7のある鯖)でユーザーIDとパスワード(ランダム作成)入力
※これはこちらで決めて配布
▼削除プログラム起動時
1. ログイン後にサブキー、使うスキル呪文を入力(コレもある意味パスワード)
2. IDとスキルを照合して起動許可があるか確認(スキル使用許可)
3. 実施結果が真なら、該当削除スクリプトの起動を許可
※個別のスクリプト名を変更しなくても、必要ならスキルの呪文も変更が
管理者レベルで可能にする。
※入口(ユーザーログイン)からの起動以外は受け付けない。
※ユーザーログインの入口は、必要に応じて呪文かえるのもあり
---
▼サブキー管理
1. 削除フロントからサブキーの紐付け登録を実施
2. 二次キーを生成して照合用DBへ登録
※このとき、登録日時を記録
※サブキーは、文字列でも可か?(暗号化して保存?)
※二次キーの生成は、管理者が任意に実施
少々簡略化してしまってる気がしますし、不十分っぽい気がしますが、
必要なところは修正してください(あくまでイメージなので)。 >>346
スキル呪文と言うか、起動させたいプログラム名で制御ってのより、
アカウントにぶら下げで使えるスクリプトを制限してしまう方がUIとしては良いのかもと思ったり
>>権限DB
0 | Aさん | スレッド削除、レス削除、スレッド移転
1 | Bさん | スレッドストッパー、スレッド削除、レス削除
↓
・Aさんの画面
┌───────────┐
│ようこそAさん │
│ 1st key .[ ] │
│ 2nd key [ ] │
│ │
│・スレッド削除 │
│ 鯖 [ ] │
│ 板 [ ] │
│ スレッドキー[ ] │
│----------------------│
│・スレッド削除 │
│ 鯖 [ ] │
│ 板 [ ] │
│ スレッドキー[ ] │
│ レス番 [ ] │
│----------------------│
│・スレッド移転 │
│ 元鯖 [ ] │
│ 元板 [ ] │
│ 元スレッドキー[ ] │
│ 先鯖 [ ]│
│ 先板 [ ]│
│ 先スレッドキー[ ]│
└───────────┘
・Bさんの画面
┌───────────┐
│ようこそAさん │
│ 1st key .[ ] │
│ 2nd key [ ] │
│ │
│・スレッドストッパー │
│ 鯖 [ ] │
│ 板 [ ] │
│ スレッドキー[ ] │
│----------------------│
│・スレッド削除 │
│ 鯖 [ ] │
│ 板 [ ] │
│ スレッドキー[ ] │
│----------------------│
│・スレッド削除 │
│ 鯖 [ ] │
│ 板 [ ] │
│ スレッドキー[ ] │
│ レス番 [ ] │
└───────────┘ >>347補足
1st keyと2nd keyから合成キーを生成
→これで紐付け照合 >>347じゃ使い物にならないよ
削除画面絶対反対 >347
find.2ch の「こそアン」と同様
1st keyと2nd keyの入力は画面の下に表示した方がいいかと
1st keyにスキル呪文いれれば… >>341
おいらのことかー!!
なるべくシンプルに作ったほうがいろいろといいんじゃないかな・・・ >>347
それではちょっと駄目ですね・・・。
アカウント入力だけでそこまでの画面に辿り着けるのは
まずいと思っています。
プログラム名で制御しなくてもいいんで、あくまで使うスキルの
パスワードというか暗号というか、、、
スキルパスってことにしましょうか?
というか、いままでののUIのイメージを伝えられないので、
(事細かにあまり書けないので)何というか・・・。
どうしましょうかねぇ。 じゃぁ削除人にはスキルごとのアカウント発行すればいいんじゃね。
名前・パス・スキルの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