追記（19日）東洋経済オンラインの的外れ記事 / 高木浩光＠自宅の日記 - 治外法権のeLTAX、マルウェア幇助を繰り返す無能業者は責任追及されて廃業に追い込まれよ
■ 治外法権のeLTAX、マルウェア幇助を繰り返す無能業者は責任追及されて廃業に追い込まれよ ここ数年、不正送金の被害がインターネットバンキングの法人口座で急増しているという*1。その原因は今更言うまでもなく、Java実行環境（JRE）やAdobe製品の古いバージョンの脆弱性を突いてくるマルウェアである。しかしそれにしても、法人口座を扱うパソコンがなぜ、Java実行環境やAdobe製品をインストールしているのだろうか。インストールしなければ被害も起きないのに……。 その謎を解く鍵が、eLTAX（地方税ポータルシステム）にあるようだ。eLTAXでは、インターネットバンキングの口座を用いた納税ができることから、インターネットバンキング用のパソコンでeLTAXの利用環境も整えるということが普通になっていると思われる。そのeLTAXが、昨日までは、Java実行環境のインストールを強要していた。eL
OWASPのSQLインジェクション対策方針を読んで「おまえは俺か」と思った
つい最近まで、グローバル・スタンダードのセキュリティ施策ではバリデーションが極めて重視されている、いささか過剰ではないかと思っていたのですが、OWASPの文書を読みなおしたところ、これは僕の思い過ごしだったかと思い始めました。あくまでOWASPに限った話ではありますが… OWASP Top 10 2004については、以下のようなプレゼンをしたことがあります（2012年3月27日）。 ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ OWASP Top 10 2004をはじめとして、バリデーションが過剰に重視されているのではないかという指摘でした。 しかし、最近OWASPの文書を読みなおしてみると、OWASP Top 10 2004当時にあった「バリデーション至上主義」のようなものはすっかり影を潜め、私が（そして日本の専門家の多くが）言っていることとほとんど変わらないことに
今どきのSQLインジェクションの話題総まとめ - PHPカンファレンス2015発表資料
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
高木浩光＠自宅の日記 - GPS捜査の総務省ガイドライン改正で携帯電話事業者と警察が不正指令電磁的記録の罪を犯すおそれ
■ GPS捜査の総務省ガイドライン改正で携帯電話事業者と警察が不正指令電磁的記録の罪を犯すおそれ 目次 経緯 刑法168条の2 不正指令電磁的記録に関する罪 パブリックコメント提出用意見書（期限超過） 4月にこういう記事が出ていた。 携帯GPS情報、本人通知せず捜査に活用 指針見直しへ, 朝日新聞, 2015年4月17日朝刊 総務省が、通信事業者の個人情報の取り扱い方を定めるガイドラインの見直し案を17日に発表する。意見公募の手続きを経て、6月にも運用がはじまる見通しだ。 （略）捜査機関が、裁判官の令状にもとづき、GPS情報を取得できる規定がガイドラインに盛り込まれたのは2011年11月。誘拐犯や指名手配犯の居場所の把握に有効と考えられた。ただ、プライバシーへの配慮から、取得を本人に知らせる「条件」つきだった。 だが、被疑者に知られると証拠を隠されたり、逃げられたりする恐れがある。誘拐犯な
上原 哲太郎/Tetsu. Uehara on Twitter: "怪しいメール開く方がアホだろ見たいな話が出回っているようなので、7年ほど前に私が受け取ったメールを晒しておきますね（一部隠してます）。これを「怪しい」って判断できる人は大したもんだと思います。今はもっと巧妙だし。 http://t.co/SwKNkH4t9s"
怪しいメール開く方がアホだろ見たいな話が出回っているようなので、7年ほど前に私が受け取ったメールを晒しておきますね（一部隠してます）。これを「怪しい」って判断できる人は大したもんだと思います。今はもっと巧妙だし。 http://t.co/SwKNkH4t9s
ssig33.com - よく分からない人のためのセキュリティ
いろいろと原則論はあるんですが。昨今のアプリケーションは複雑化し、扱う情報はよりセンシティブになり、そしてより幅広く使われるようになっています。よって「安全な」アプリケーションを作るために必要な知識はますます増える傾向にあります。 よく分かってない人は以下のことにとりあえず気をつけましょう 1. なるべく自分で作らない これは最も重要なことです。検索する、他人に聞く、自分で考えない。これは重要です。大抵の問題は他人が作ってくれた解決策を適用できます。 例えばセキュアな問合せフォームを作ることにしましょう。気をつけるべきことは以下のことぐらいでしょうか。 送信内容の確認画面を表示する場合、ユーザーの入力した値は適切にエスケープするように 送信内容をアプリケーションの DB に格納する場合には SQL インジェクションを防がなければならないので、プリペアドステートメントを用いる CSRF 対策
「セキュリティ対策」
「不正な入力に対して脆弱性を発生させないようセキュリティ対策としてバリデーションを行う」。アホか。プログラマならセキュリティ対策とか気にするな。いや、気にするなというのは言い過ぎだけれど、ほとんどの場合においてあなたの書くコードはセキュリティ対策の必要性はない。 攻撃者の細工した入力によってSQL/HTML/JavaScriptが壊れるとかバッファオーバーフローが発生するとか、そういった脆弱性と呼ばれるほとんどのものはただのバグだ。セキュリティ対策っていうのはコードとは切り離された領域で行うDEPだったりASLRだったりX-Frame-OptionsだったりCSPだったりiframe sandboxだったり、そういうものがセキュリティ対策だ。コード上で書くのは「アプリケーションとして正しく動作するための処理」だけだ。 もちろん例外もあるかもしれないけど、それはあくまでも例外だ。日常的に書く
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
