「HTTP」を含む日記 RSS

はてなキーワード: HTTPとは

2019-01-16

https://anond.hatelabo.jp/20190116122939

騙されるな、http圧倒的多数や。anond粘着して数を稼いでるだけやでぇ!!

anond:20190116122504

別にanond:記法を使わずhttp:でトラバするのが悪いことだとは言わないけど

ヒートアップしてるツリーでそういう癖を出すと「やっぱりこっちサイドで頑張ってるの一人だけじゃん」ってすぐバレちゃう

2019-01-12

スクールに通って未経験からwebプログラマ転職して一発逆転!!

を狙ってるそこのお前

どうせお前のスキルセットは「html,css,js,rails」だろ?

揃いも揃ってそんなんばっかり

スクール講師に言われるがまま

このご時世にjqueryでせっせとDOM操作して

プリプロセッサも使わずしこしこcss書いて

HTTPメソッドSQL理解せずにそれっぽく動くN+1だらけのクソ作っただけだろ?

webプログラマ目指すくせに開発環境構築にDockerも使わず理解してないコマンドコピペしてローカルに直でインストール

せっかく無料枠あるのにawsじゃなくてHerokuにプッシュするだけのデプロイ

テストコードも書かず

CI/CDツールも使わず

ブランチ運用なんて考えずmasterブランチに直プッシュか?

会社に入れさえすれば先輩がつきっきりで教えてくれるとでも思ってんのか?

先輩を質問責めにする気か?

むりむりやめとけ

そんなんじゃせいぜい年収300

諦めた方が身のため

あばよ


どうしてもなりたいなら↑で挙げたものぐらいは最低限を理解しとけ

メモ帳一つでプログラマ」なんて時代は終わったんだよ

ここまで言って調べる気にならないなら本当に向いてないよ

2018-12-25

anond:20181225105947

キミの世界でのプリンタ

PCドライバ必要ないし

複合機にそのままファイルを投げて

複合機が解析印刷するわけか

これが、現実世界の話だってことはわかってくれ

変換必要ないんだよ

HTTPとかFTPとかLPRとかの汎用プロトコルファイルを投げるとプリンタ側で解析印刷してくれるんだよ

2018-12-21

togetterリダイレクトスパム履歴にこれが残ってた。

data:text/html;base64,PG1ldGEvaHR0cC1lcXVpdj1yZWZyZXNoIGNvbnRlbnQ9MDt1cmw9aHR0cDovL2FkY2xpY2suZy5kb3VibGVjbGljay5uZXQvcGNzL2NsaWNrP2FkdXJsPWh0dHBzJTNBJTJGJTJGYmVzdHNhZHNzYWxlLmNvbSUyRnBhZ2UlMkYlM0YyVldJams1NmpRTDdiaEpWQ1YycGVVbjdMPg==

デコードたらこうなった

<meta/http-equiv=refresh content=0;url=http://adclick.g.doubleclick.net/pcs/click?adurl=https%3A%2F%2Fbestsadssale.com%2Fpage%2F%3F2VWIjk56jQL7bhJVCV2peUn7L>

2018-12-18

(PHP) phpMyAdminのセキュリティー

アドバイスどうもありがとうございます

https://anond.hatelabo.jp/20181218231219

本番サーバには入れないでね

phpMyAdminセキュリティーって、過去の事例を見ると、あまり高くないようですね?

この手の管理ツールセキュリティ侵害を受けた場合ダメージが大きいので、インターネットからアクセスできないようにしておくのが基本です。特にphpMyAdmin過去に致命的な脆弱性が何度も発見されており、インターネットさらして利用するには向いていません。任意コード実行可能脆弱性の事例もあり、DB以外にもリスクがあります

 

内部ネットワークからしかアクセス出来ないようにしておきましょう。レンタルサーバのようなインターネット孤立したサーバであっても、VPNの経路を作りそちらからしかアクセス出来ないようにしておくようにした方がよいでしょう。

 

IPアドレスによる制限は次善策です。アクセス元のIPアドレスが固定されており他人と共有していないならそれなりに安全になります

 

URLによる隠蔽は外部から攻撃可能な既知の脆弱性スキャンするようなカジュアルアタック避け程度にはなりますが、URLは何かと漏洩するものですので、一般セキュリティ手法と見なされていません。

 

アクセス制限をした場合でも、認証は必ず設定する必要があります。例えばCSRFのような攻撃にはアクセス制限無意味です。

 

phpMyAdmin認証HTTP認証のどちらを使う方がよいかは使ったことがないのでわかりませんが、HTTP認証場合BASICではなくダイジェスト認証にしてください。BASIC認証は(ほぼ)生で認証情報が流れますので使ってはいけません。(ブラウザで人が操作する場合以外にはBASIC認証を使わざるを得ない場合もあります

対応

  1. phpMyAdminローカルの開発サーバーで使う。
  2. 本番サーバーのMySQLメンテナンスときだけ、Adminer.php等を使う。(使用前にコピーして、使用後は削除する) もしくはMySQLコマンド操作する。

こんなかんじでしょうか?

2018-12-09

anond:20181209225623

仮想マシンネットワーク設定を確認してみる必要があるんですね。

 

とりあえずググりまくって、Ubuntuネットワーク状態を調べる方法を試してみました。

ip address show

この結果を見ると、ポート番号8000が使われてないかんじでした。

これを常時開けておいて、HTTPアクセスがあったとき使うように設定する必要がありそうですね?

 

参考になりました。

どうもありがとうございました。

2018-12-02

[] Webプログラミング面白いほどわかる本

みんなで一緒に勉強してみよう!

 

Webプログラミング面白いほどわかる本 環境構築からWebサービスの作成まで、はじめからいねいに (N高校プログラミング教育) 単行本 - 2018/6/22

吉村 総一郎 (著)

https://www.amazon.co.jp/dp/4046023023/

https://www.kadokawa.co.jp/product/321712000860/

 

サーバーサイドの入門に最適な、Webプログラミングテキストが登場!

Linuxでの環境構築からGitGitHubによるコード管理Node.jsによるサーバーサイドのプログラミングが学べる!

インターネットで学ぶ話題通信制学校「N高校」が展開する、プログラミング教育メソッド大公開第2弾!

約1000人の高校生にWebプログラミングを教えてきた名物講師が、入門者がつまずきやすポイントを、ていねいに解説!

 

【本書の対象読者】

環境構築で挫折した方

サーバーサイドに挑戦したいと思っている方

SIerからWeb系への転職を考えている方

 

【本書の内容】

■Chapter1 Linuxの基本を身に付けよう

LinuxというOS

コンピューター構成要素

コマンドファイル操作する

標準出力

viの使い方を学ぼう

 

■Chapter2 シェルプログラミングをやってみよう

シェルプログラミング

通信ネットワークサーバークライアント

HTTP通信

通信をするボットの開発

 

■Chapter3 GitHubで始めるソーシャルコーディング

GitHubでWebサイトを公開する

イシュー管理Wikiによるドキュメント作成

GitGitHub

GitHubへのpush

Gitブランチ

ソーシャルコーディング

 

■Chapter4 Node.jsプログラミングをやってみよう

Node.js

集計処理を行うプログラム

アルゴリズム改善

ライブラリ

 

■Chapter5 Slackボットを作ろう

Slackボット開発

HubotとSlackアダプター

モジュール化された処理

ボットインタフェースとの連携

 

■Chapter6 HTTPサーバーを作ってみよう

同期I/Oと非同期I/O

例外処理

HTTPサーバー

 

Webプログラミング面白いほどわかる本」を出版させてもらいました

https://note.mu/sifue/n/n69fdeadc4612

この本の利用の想定としては、Webプログラミングサーバーサイドにチャレンジしていきたい方や、システムインテグレーターとしてWebプログラミングを知らずに仕事をしてきたシステムエンジニアの方が、Webプログラミングを学んで行くための下準備の知識を蓄えるために利用することを想定しています

 

実際、N予備校プログラミング入門コースは、Web業界Web活用する企業の社内エンジニア研修テキストとして利用して頂いている事例も増えており、本書の内容の学習必要とされている場所は増えて来ていると感じています

 

2018-11-28

7年勤めたNTT系列退職して2年半が経過しました(ノンキャリア編)

2年半ほど経ちますが、空前のNTT退職ブームなので便乗しちゃいます

はじめに

まず既知の通りNTTグループ社員数約28万人と非常に大きな組織であり、その中で研究所エリート中のエリートが就く位置にある。つまり上記の方達は警察でいえばキャリア組にあたる方達にあたる。以降キャリア組と呼ばせていただく。

一方で、私は地方ノンキャリア警察官のようなポジションにある子会社大株主研究所出身なので、その分際でこのようなエントリーを書くのはおこがましいかもしれないが、

キャリア組層のエントリーなのに共感できる部分がとても多い上に、すでに [ 10年勤めたNTT退職しました(無能編) https://anond.hatelabo.jp/20181126192228 ]のようなノンキャリアそうな人(←失礼はご愛嬌)のエントリーもあったりしたのでちゃっかり便乗させてもらう。

蛇足


自己紹介

自分について


会社について

データとデー子もこんな感じなのだろうか。ぜひ知りたいものだ。

よかったところ

各種エントリーと重複するところもあるがご愛嬌

いい人が多い
  • いい人の定義が難しいが、穏やかで真面目な人が多い。飲食店バイト時代のように「ボケコラ○すぞ」なんていう上司はまずいない。
  • たまにチート級の有能な人がいる。知っている人では今でも有名OSSプロジェクトコミッターやってたりとか。
  • たまにチート級の無能な人がいる。知っている人では開いてはいけないメールを毎回開く人とか。でもクビにも降格にも絶対にならないいいところ。
  • それ以外は可もなく不可もなく凡人。僕もその一人。思えば2-6-2の法則はよく出来ている。

法令遵守

金が腐るほどある



悪いところ≒退職理由

給料が安い

できる人もできない人もすべて同じ待遇

独自プロトコルが大好き

技術に興味がない人が多い

社内システムう○こ

その他

総評

2018-11-20

DBを「デービー」っていうのは日立に限らず業界標準じゃないか

HTTPを「エイチテーテーピー」っていうのは日立だけ

2018-10-29

はてなブックマークコメントフォームhttps対応してない件

ブクマ一覧とか読み取り専用ページがhttpなのはそれなりのポリシーがあるかと思ったら入力フォーム存在するURLもそうなのは流石にアウト。

何故やらないのか。流石におかしい。

2018-10-19

何でリテラ表示されてんだよぉ〜ブロックしただろぉ〜

httpsになったんですね

ブロックリストhttpだったからすり抜けてきたか

2018-09-22

JWTに関してのお伺い

http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session

適当コメントを書いたら

スーパーエンジニアに「そういうことではない」

と厳しい叱責を受けたため、無能の見識を書いてみた。

「聞くは一時の恥、聞かぬは一生の恥」のとおり、

せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存

expの期限と任意セッションが切れないデメリットに対する私見

作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)

私は無能なのでたぶんユーザーから報告を受けて

確認している間に1時間はかかるからいいやと思ってしまっていた

師はきっとJWT生成直後3秒でユーザー

「これは、セッションハイジャックか・・・!?

と気づいて通報

そして師が2秒で

「これは、セッションハイジャックだ!」

と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している

これは確かにJWTだと厳しそうだ

そもそもログインできるアプリなら

セッションハイジャック成功直後にパスワードを変更された場合

セッション任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか

(師はログインを即座に検知してセッションを切れるから問題ないのか)

とにかくアカウントロック機能を作れば上記懸念全てにきれい対応できそうに見えている

「定期的な鍵交換が必要」に関する私見

この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える

これはまずい、自分の今までの見識の甘さを思い知らされた

今使っているフレームワークリファレンスを見たが

keyは初回に設定したのみで、定期的な交換を勧める文が見つからない

私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか

JWTはhash化してつないでいる前提で

hashのkeyを総当たりで破る仮定で書く

私は無能なのでライブラリを用いることにしている

32文字keyが生成された

解読時間は下記を参考に、計算windows10電卓アプリを用いて手動で行った

https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83

数字大文字文字で約60の時は10桁で20万年と書いているが

現代の解析技術20万倍は速度が出ると仮定して1年として計算する

果たして、どのくらいの速度で鍵はやぶられると推定されるのか

とりあえず60を10乗した時点で(20文字相当)

6.0466176e+17

日本語に直すと60京4661兆7600億年かかる計算となった

実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ

これだけ長くともkeyの交換は必要なのであろうか

そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか

「JWTはセッションIDを含めれば安全」に関する私見

から「そういうことではない」と指摘された点である

私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる

まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと

JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークン実装しなかったことを告白しておく

そのためapiサーバ上記前提で用いた場合に考えたことを書く

webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく

JWT送信→user_id取得

では危険

JWT送信セッション(cookie形式?)送信切り替え→セッションからuser_id取得

だと安全になるのか検討する前提で記載する

とりあえず思いついたのは下記だった

通信途中で傍受されてログイン情報が奪われる危険が上がる
アプリから直接ログイン情報が奪われる危険が上がる

通信途中で傍受される危険に関して

tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能識別子)が含まれ

おそらく一般構成仮定で書く

https通信するのでパケットキャプチャによる傍受は不可能と思っていた

(http通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)

0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない

というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので

JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった

※余談だが、たまに送る回数が少ない方が安全という

言説を見るのだが、個人的には上記理由で納得できていない

アプリから情報が抜かれる危険性に関して

クライアントネイティブアプリ場合

攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた

(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)

その前提のため、わざわざ

JWT送信セッション(cookie形式?)送信セッションからuser_id取得 

接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる

まりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった

結論

まりcookieだろうがjwtだろうがidpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメント発言に至った

ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが

それならもっと無駄なため考慮しない

セッションにするメリットとして唯一思いついているのは任意サーバ側でセッションを切れることだが

それを指していたのであろうか

それは最初段落問題と同一と思っている

余談だが、ブコメ雰囲気日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)

というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが

結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので

正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている

強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか

でも暗号化したらよいのでは、と思った

私的結論

expの期限と任意セッションが切れないデメリットに関して

expを適切に設定しつつ、必要ならアカウントロック機能を入れる

(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)

定期的な鍵の交換について

長いkeyを設定すれば不要

「JWTはセッションIDを含めれば安全」について

少なくともapiサーバネイティブアプリに関して、セッションIDを含めても危険性は変わらない

正直webアプリでも大して変わらんのでは、と思っているのは内緒である

と思ったので短慮なところ、見落としている視点があるようなら今後のためにご教示をいただきたく

以上、よろしくお願いいたしま

2018-09-09

はてブはもうhttphttpsのエントリーを同じ扱いにしなよ

httphttpsで別のコンテンツが表示されるサイトなんて皆無だろ。

同じユーザブクマは両方維持することもできそうだし、エントリーページにHSTSのフラグを持つようにすればいけんだろ。

anond:20180909092548

2018-09-03

ブコメ比較 はちま

http://www.tenohirakuru.info/?onlyComment=true&url=http%3A%2F%2Fnlab.itmedia.co.jp%2Fnl%2Farticles%2F1612%2F28%2Fnews088.html%2Chttp%3A%2F%2Fblog.esuteru.com%2Farchives%2F9182504.html

上:まとめサイトはちま起稿」、DMM.com運営していたことが判明 - ねとらぼ

下:「10歳の時、父が10万円を渡して言った。このお金は好きに使っていい。ただし毎月のお小遣いは君の持ち金の1%だ」はちま起稿


b:id:nisisinjuku

ゲスカプw

インベスターZみたいなお父さんだねw まぁ、嘘松でもいいさ、意外と核心をついている部分もあると思うぜ。そうして僕はすぐにコンビニに向かった!

b:id:lbtmplz

またIT企業=悪人の図式かー

倍プッシュだっ…!

b:id:white_rose

よくあんサイト買収するな……。まあ似た者同士か

「おこずかい」が気になってしまって。中学生から毎月本やノート(??)に投資してるのに

b:id:otihateten3510

どんどん出てくるw

うそまつううううううううわあああああああああああああああああああ

b:id:quality1

これは結構大きなニュースでは

このお父さんだからできただけでそこらの親がやってもうまく行かなさそう

b:id:sekreto

そんな一大事なの?

月利1パーセントなら、みんなからお金をかき集めるべき。

b:id:YukeSkywalker

DMMの糞カウンターが爆上げ中。

何やはちまか。開いて損した。

anond:20180903193133

2018-08-31

anond:20180831001950

Webって仕事はいっぱいあるけどつまんないよ。やってることはユーザー入力に応じてDB操作して、DBの内容を画面に表示するという、よくある業務系と変わらんし。ただ、途中にHTTP挟んでるのとレンダリング基本的HTMLというのが特徴(というか足かせ)なだけ。プログラミング面白い部分はほとんどフレームワークカバーしてるから、残ってるのは細々としたすり合わせばかりだし。

2018-08-18

俺にはAndroidアプリ開発なんて無理だわ…

Android Studioダウンロードして公式チュートリアルやってるんだけど、いきなりつまづいたし。

アプリ実行できないし。

https://developer.android.com/training/basics/firstapp/running-app

まで来たけどビルドが出来ないし。(ビルドじゃないのか、gradle sync?とかいうやつ?)

org.gradle.internal.resource.transport.http.HttpRequestException: Could not HEAD 'https://jcenter.bintray.com/org/ow2/asm/asm-analysis/5.1/asm-analysis-5.1-sources.jar'.

とか言われとるし。

ネット環境ちゃんとあるのに。

プロキシかいらんことしてないのにし。

上のjarドメインping送ってみたら100%ロスしとるし。

オンラインping送信サービス使っても同じだし。

そのせいか

Android Studio で、[Project] ウィンドウの [app] モジュールクリックしてから、[Run > Run] を選択しま

RunRun選択できないし。

グレーアウトしとるし。

もう意味分からんし。


いや、多分サーバーが死んでることが問題なのは分かる。

からないのは、ネット環境がないとアプリを実行することすら出来ないということだ。

サーバーが死んでたらその間何も出来ないのか。

そしてツイッターで誰も何も言ってないの見ると、誰も大した問題だと思ってないのか。

もう良い。俺にはAndroidアプリ開発は合わない。

Android開発者はこんな地獄の中頑張って開発してる自分を褒めたほうが良い。

じゃあの

追伸: このbintray.comとかいうクソがどこかのボットネット攻撃されて使い物にならなくなりますように。

2018-07-20

ハテブってアホなの?

BBCの全く同じ記事URLhttphttpsで別エントリ分散してる

そういうのシステムでまとめろよ

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん