読者です 読者をやめる 読者になる 読者になる

サーバー周りメモ

レンタルサーバーの選び方
www.cpi.ad.jp
VPS/PaaS/クラウドどれにすべきか
morizyun.github.io
Sqale
blog.inouetakuya.info
Sqale
sqale.jp
phpmyadminじゃなくて
iritec.jp
サーバーに入る方法
gihyo.jp

SSHはネットワークを介してサーバにログインできるサービスを提供します。
それにより,リモート(=遠くにいてネットワークでつながっている)のサーバと,自分が使っている目の前のパソコンとを安全につながることができるのです。ちなみにSSHはSecure Shellの略です。このShell(シェル)は,ユーザの操作を受けとって,そこから与えられた「ファイルをアップする」や「ファイルを削除する」などの指示をサーバに伝えるソフトのことです。SSHが自分のパソコンとサーバを繋いでくれることで,遠くにいるサーバにファイルをアップロードしたり,操作したりすることができます。しかもこのときネットワーク上を流れるデータは暗号化されるため,一連の操作はすべて安全に行うことができます。サーバにはSSHの「パスワード認証」または「鍵認証」で入ります。「鍵認証」とは,事前に自分のパソコンの中で秘密鍵と公開鍵の鍵ペアを作っておき,公開鍵だけをサーバに設置しておくというやり方です。この鍵認証方式はちょっと複雑です。秘密鍵で作った暗号はペアの公開鍵でしか解けず,公開鍵で作った暗号はペアの秘密鍵でしか解けないという性質を利用して認証しています。なんだか難しいなと思った方は,とりあえず秘密鍵が鍵で,公開鍵が鍵穴なんだと思ってください。

FTPTelnetだと通信内容は暗号化されず,そのまま(平文)で送られるため,通信経路を盗聴されるとアカウントやパスワードが簡単に盗まれてしまうという問題点があります。そこで最近はFTPではなく,SSHの仕組みを用いた「SFTP」(SSH File Transfer Protocol)や「SCP」(Secure Copy)というファイル転送の仕組みがよく使われています。SFTPやSCPなら,たとえ通信経路を盗聴されても,そこを流れていくアカウントやパスワードは暗号化されているので安全です。データが中の見えないトンネルを通っていくようなものです。

CSRF

CSRFを簡単に言うと、ユーザー情報を盗み取り、アカウントを使って悪さすることだ。正規のサイトをA、攻撃用のサイトをBとする。ログイン中のユーザーがAと見た目が同じBにアクセスし、Aに向けて何かしらリクエストを送った場合、Aが「ログイン中かつPOSTをした」ということしかチェックできなければ、不正アクセスを許し結果としてユーザー情報をBに抜き取られてしまう。
対策としては、そのページから送られたということを確かめることができればいい。

CSRF(クロスサイトリクエストフォージェリ) | PHPの入門・リファレンス

CSRF・・・ユーザの意図しない操作を、そのユーザの権限で実行させる不正です。例えばログインしないと実行できない操作があったとして、それらの操作を不正に"そのユーザに"実行させてしまう攻撃です。意図しない商品購入、退会処理、不正投稿などの被害が考えられます。
対策・・・秘密情報を使用し、正規のリクエストかどうかチェックをすることで防ぐことができます。
 上記の例に対して対策を行うこととし、具体的な手順を示します。正規のページでは、"post"の送信と共に、hiddenで秘密情報を送信させます。そしてその秘密情報はセッションでサーバ側でも管理し、リクエストにこの秘密情報が正しく含まれている場合にのみ処理を実行するようにします。この秘密情報をランダム文字列で生成すれば、サーバ側、ユーザしか知り得ない情報のため、攻撃者は推測することができません。秘密情報はセッションIDや、別のIDを任意に生成するなど方法はいくつかありますが、必要なのは攻撃者が予測できない文字列であることです。(ワンタイムトークンを用いた対策例が多く紹介されていますが、必ずしもワンタイムである必要はないと思います。)

build-web-application-with-golang/09.1.md at master · astaxie/build-web-application-with-golang · GitHub

www.slideshare.net

http://www.websec-room.com/2013/03/07/479

[PHP] メールフォームのCSRF対策 – 端くれプログラマの備忘録

CSRF対策の基本は、「サーバーがフォームのサブミットを受信したとき、それが自分が生成したフォームからのモノであるかどうかを確認する」こと。具体的には、自分がフォームを生成するときにはトークンを埋め込んでおき、フォームを受信したときにそのトークンが存在するかどうかを確かめればよい。

クロスサイトリクエストフォージェリ(CSRF)[トークン][PHP]

dotinstall.com

dotinstall.com

対策すべきセキュリティ項目

liginc.co.jp
gozal.cc
qiita.com

viral-community.com

「悪意のあるスクリプト」を埋め込むためには、Webサイト上に入力フォームがある必要があります。 例)掲示板
この入力フォームに「悪意のあるスクリプト」を埋め込むわけですね。「スクリプト」とは、一般的に「javascript」を指します。入力フォームに「javascript」を埋め込む事が、クロスサイトスクリプティングXSS)の基本的な手法になります。
クロスサイトスクリプティングXSS)による脅威は、様々なものがあるんですが、例(有名どころ)として下記二点を解説していきます。
・訪問者のクッキー情報を抜き取るスクリプトを埋め込む事による「セッションハイジャック
・訪問者の個人情報の入力を促す入力フォーム(HTMLタグ)を埋め込むことによる、個人情報の不正搾取
クロスサイトスクリプティングXSS)は、「<」と「>」などの文字を、特殊文字(タグ)として認識するブラウザの仕様を利用した攻撃手法になります。
対策
クロスサイトスクリプティング対策としてやるべき5つのこと | 三度の飯とエレクトロン
d.hatena.ne.jp
http://www.websec-room.com/2013/03/19/636
qiita.com

  • スクリプトインジェクション・・・JavaScriptなどを埋め込んだメッセージを投稿し、第三者に表示・実行させる攻撃

不正アクセスへの対策 | PHP Labo

sqli.md · GitHub
対策:すべてのパラメータを正しくエスケープするか、プレースホルダを使う。
俺の脳内選択肢が、SQLインジェクション対策を全力で邪魔している — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something
qiita.com

  • クロスサイト・リクエスト・フォージェリー (CSRF)

リクエスト強要(CSRF:Cross-site Request Forgery)とは、別のサイトに用意したコンテンツ上の罠のリンクを踏ませること等をきっかけとして、インターネットショッピングの最終決済や退会等Webアプリケーションの重要な処理を呼び出すようユーザを誘導する攻撃である。

www.ipa.go.jp

qiita.com
qiita.com

・セッション固定攻撃に対する対策
ログイン後にsession_regenerate_idを必ず実行する.
ログアウト後にsession_destroyを必ず実行する

ディレクトリ遡り攻撃
不正アクセスへの対策 | PHP Labo
データファイルへのブラウザ経由(http://〜)でのアクセスを拒否する方法


d.hatena.ne.jp

セッションとクッキー

www.geocities.jp
以下、上記事からのまとめ

セッション管理:クライアント・サーバーの間で通信や情報を管理・保持すること
セッションID:コンピューターの相手を認識するための道具
session:クライアントとサーバーとの接続期間

セッションIDは、その接続は誰が行っているのか特定する物。
セッション変数は、その接続を行っている人物に関連する情報を保管するための変数だ。
セッション変数は、セッションIDと紐づけされるため、セッションIDがあれば、個々の接続の際に保管したデータを取り出す事ができる。

①クライアントから情報が送信される
②webサーバーがクライアントの情報をデータベースに保存する
③webサーバーがクライアントにセッションIDを渡す。
 このセッションIDによって、セッションIDと認証許可の情報が紐づけられているので、webサーバーはクライアントを判別することができる
④クライアントはサーバーから与えられたセッションIDを保持する。
 セッションIDをブラウザに覚えさせる方法
  (1).クッキー(cookie)を使う。→つまり、CookieとはWEBサーバーが発行し、ブラウザが保持するキーと値。
    Cookieはブラウザに保存され、セッションはWEBサーバーに保存されるという点が重要。
  (2).URLの後ろのセッションIDをつける。
⑤クライアントはサーバーから与えられたセッションIDを使い、サーバーが現在の接続を識別できるようにする。

・セッションIDは、クライアントに覚えさせるクッキー値なのだ。
1回目の接続の際、クライアントが接続要求を行う。
サーバーはセッションIDを発行し、それをクッキー値としてクライアントへHTMLデータと共にセッションIDを送り、ブラウザに覚えさせる。
そして2回目以降、クライアントが接続要求を行う際に、前回の接続でサーバーから送られたセッションIDを送る。
サーバーは、クライアントから送られたセッションIDを見てどの接続かを判断し、接続応答でHTMLデータをクライアントへ送る際に再び、セッションIDをクッキー値としてブラウザに覚えさせる。

セッションハイジャックとは
セッションIDがあれば、ログイン後の画面を簡単に見れてしまうのだ。
クライアントからサーバーにセッションIDを送信する際に、盗まれないようにしなくてはならない。
セッションハイジャックを防ぐ方法として、クライアントとサーバーの間はSSL通信(通信データの暗号化)を行う方法がある。
それ以外にも方法がある。 1回きりのセッションIDを使う事だ。→session_regenerate_id();
接続を行う度に、セッションIDを変更しておけば、例え、セッションIDが盗聴されたとしても、盗聴される危険性が減る。

bootstrap メモ2

websae.net

qiita.com

グラフィックデザイナーのためのCSSレイアウトメモTIPS「position : absoluteについて」
position:relative;を解除したらナビゲーションバーとの重なりがなくなった

websae.net
グリッドシステムについてわかりやすい

Bootstrap | Webお役立ちネタ帳


qiita.com
わかりやすい

qiita.com


とほほのBootstrap入門
これもよくまとまっている

bootstrap3-guide.com
bootstrap3。よくまとまっている

cccabinet.jpn.org
bootstrap3移行ガイド

ui-cloud.com
いろんなパーツが揃っている。めちゃ便利。

qiita.com
いろんなデザインが簡単に作れる

bootstrap メモ

BootStrapでcontainerの幅を変更する方法
BootStrapでcontainerの幅を変更する方法jinseisaikidou.wordpress.com

わかりやすい
designup.jp
上のデモ
Wireframe to Responsive

qiita.com

http://wpcos.com/?p=14727

githubじゃなくてbitbucketいいよ

bitbucketだとプライベートレポジトリを無料で使えるということなので、githubから移行しました。
移行手順は下記を参考に
akiyoko.hatenablog.jp

これは便利