タグ

2016年12月28日のブックマーク (5件)

  • PHPMailerの脆弱性CVE-2016-10033について解析した

    エグゼクティブサマリ PHPMailerにリモートスクリプト実行の脆弱性CVE-2016-10033が公表された。攻撃が成功した場合、ウェブシェルが設置され、ウェブサーバーが乗っ取られる等非常に危険であるが、攻撃成功には下記の条件が必要であることがわかった PHPMailer 5.2.17以前を使っている Senderプロパティ(エンベロープFrom)を外部から設定できる 現在出回っているPoCはMTAとしてsendmailを想定しており、postfixを使っている環境では問題ない 対策版として公開されている PHPMailer 5.2.19も不完全であるので、回避策の導入を推奨する。 はじめに 12月24日にPHPMalerの脆弱性CVE-2016-10033が公表され、とんだクリスマスプレゼントだと話題になっています。 PHPからのメール送信に広く使われているライブラリの「PHPMai

  • これまで体験してきたメール送信の難しさ #SendGrid_jp – yusuke.blog

    SendGrid Advent Calendar 2016の12月22日分です。 メールを送る際、プロトコルとしてSMTPが使われていてメールサーバにはPostfixやGoogleのメールサーバなどを使えば簡単というのは割と有名です。 が、送るのは簡単だけど何かと問題が発生するものです。 私のこれまでの経験をちょっとメモしておこうと思います。 メール配信周りの運用経験1. 自宅サーバ運用の掲示板(James、2000年〜) 2000年くらいから自宅サーバで掲示板を運用していました。Tomcatで動くServlet + JSPのアプリケーションで、メールアドレスを登録しておくと新規書き込みがメールで通知されるというものです。 メールの配信にはPure JavaのメールサーバであるJamesを使っていました。 自宅サーバで運用してた(今も動いてるけど)のは勉強、練習みたいなもので特にサーバの運

    これまで体験してきたメール送信の難しさ #SendGrid_jp – yusuke.blog
    mather314
    mather314 2016/12/28
    “「メール配信をナメてかかると痛い目に遭うよ」という話”
  • コメントの9割は無駄!~アンチプラクティスから学ぶ洗練されたコメントの書き方~ #code #コード|CodeIQ MAGAZINE

    コメントは基礎的で一般的なものでありながら、「どのようなことをコメントに残すか」は経験のあるプログラマにとっても難しいもの。 この記事では、アンチパターンコメントを見ながら、どのようなコメントを残すべきかについて説明します。 by 馬場美由紀 (CodeIQ中の人) コードは機械のために、コメントは人間のために? プログラミング言語を学ぶとき、コメントは最初に習う項目のひとつです。そして、プログラムであればコメントを含んでいることが普通です。ある研究によれば、ソースコードの平均19%がコメントだそうです。 コードを書くとき、私たちは機械とコミュニケーションを取ることを意識しています。機械はコードを認識してコンパイルしたり実行してくれます。解釈できなければ教えてくれます。プログラマは、コンパイラのためにデータ型を明示するコードを書いたりもします。 一方、コメントは人間とコミュニケーションする

    コメントの9割は無駄!~アンチプラクティスから学ぶ洗練されたコメントの書き方~ #code #コード|CodeIQ MAGAZINE
    mather314
    mather314 2016/12/28
    どうでもいいけど、格言(maxim) を公理(axiom)と 取り違えている気がする。
  • 変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々

    2020-03-11追記: タイトルの「未だ」がいつなのかわかりづらいので「2012年現在」を追加しました。 バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。こういうのです。 // 2012/08/15 irof 修正開始 // hoge = fuga(1); hoge = fuga(2); // 2012/08/15 irof 修正終了 見た事無い方は、そのまま見ないままで生きていかれることを切に願います。 コメントの修正がある場合 2012/07/21にあった、SCMBCでこんなツイートがありまして。 この時点でお見せしたのはこんな感じ。 // 2012/07/21 削除開始 // // 間違ったコメント // 2012/07/21 削除終了 someMethod

    変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々
  • エンジニアの評価制度について - console.blog(self);

    Goodpatch Advent Calendar 2016 25日目の記事です。 「エンジニア向け評価制度」とは、技術やスキルなどの側面を評価するための制度という意味合い。いまエンジニア向けの評価制度を作っていて、いろいろな会社のエンジニア向け評価制度について調べてみた。 大別すると、こんな感じ。 そもそも評価制度がない エンジニア向け評価制度がない エンジニア向け評価制度がある そもそも評価制度がない 時雨堂やソニックガーデンには評価制度がない。 評価制度の無い評価制度 エンジニアの評価基準、短期評価をやめてみたら? | サイボウズ式 こういった考え方は、たしかになーと思う。 良い悪いを短期的に見ないからです。短期的に評価すると、短期的な視線で仕事をしちゃうじゃないですか? 一番イヤなのは、チームで助け合って働くのが大事なのに、“自分の評価を考えると、この人を助けている場合じゃない”と

    エンジニアの評価制度について - console.blog(self);