Spring FrameworkとDIについて - mookjp.io
Spring FrameworkとDIについて Oct 3, 2016 ( Oct 3, 2016 更新 ) DIのモチベーション ※ 参考: Spring徹底入門 CHAPTER2 一定規模以上のアプリケーションを開発するとき、各モジュールごとに実装を進めていくやり方が取られる。 例えば以下のようなインターフェースが必要になる場合。 UserService UserRepository PasswordEncoder UserServiceインターフェースを実装するUserServiceImplというクラスを実装する場合、 class UserServiceImpl implements UserService { public UserServiceImpl(DataSource dataSource) { this.userRepository = new UserRepositor
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
メインフレーム上に構築された「モノリシック」な基幹システムは、まだまだ現役です。こうした基幹システムをリプレイスする際に、複数のアプリケーションを「疎結合/高凝集」に組み合わせるいわばマイクロサービス的な設計が目指されることはよくあります。その時に重要なのは、システムをどう分割し、統合するかという方針です。 本講演では、こうしたコンテキストでドメイン駆動設計をとりあげ、アーキテクチャに関する具体的な意思決定をする方のために、有益な考え方を示すことを目指します。 受講対象: システムのマイクロサービス化を実現したい開発者の皆様、特にどのように開発をすすめていけば良いかわからない方はぜひご参加ください。 和智 右桂 株式会社ハピネット 情報システム部 新基幹開発チーム
猿でも分かる! Dependency Injection: 依存性の注入 - Qiita
はじめに アホでもわかるように解説してみるテスト。 あらゆる方向で説明してみる。 大雑把にまとめると「依存していた部分を、外から注入すること」です。 勘違い、間違いが沢山ありそうなので、是非ご指摘を! 登場人物 (用語) 依存性の注入 (日本語) Dependency Injection (英語) DI (Dependency Injectionの略語) 依存関係を設定ファイル等で定義してよろしくやってくれる「DIコンテナ」については書いておりません! 何が問題なの? クラス内などで固定化されたものがあると 柔軟性がない テストしにくい 解決方法 「依存している部分を外から注入する」 DIにおける「依存性」と「注入」の意味 依存性 (大雑把に)とあるクラスに、固定の定数、変数、インスタンスが入っちゃっている状態 つまりそのクラスは、その定数、変数、インスタンスに依存している 注入 そのクラ
閲覧でウイルス感染も「ｂａｓｈ」に重大欠陥 NHKニュース
インターネットのホームページを表示するサーバーで広く利用されているプログラムに重大な欠陥が見つかり、放置しておくと、個人情報の流出などを招くおそれがあるとして、セキュリティー機関などが早急な対策を呼びかけています。 欠陥が見つかったのは、Ｌｉｎｕｘという基本ソフト上で動く「ｂａｓｈ」と呼ばれるプログラムで、インターネットのホームページを表示するサーバーで広く利用されています。 このプログラムについて２５日、外部からコンピューターを勝手に操作されかねない重大な欠陥があることが明らかになりました。 この欠陥を悪用されると、サーバーに保管されている個人情報が流出したり、ホームページを閲覧した人のパソコンが、ウイルスに感染するよう仕組まれる危険性があるということです。 このため、セキュリティー機関のＪＰＣＥＲＴなどは、このプログラムを利用しているサイトに欠陥が修正された最新のプログラムを早急に導入
SQL識別子は結局どうすればよいか
今まで2回にわたって、SQL識別子のエスケープの問題を取り上げました。 間違いだらけのSQL識別子エスケープ SQL識別子エスケープのバグの事例 3回目となる本稿では、SQL識別子の取り扱いに関する問題を整理して､一般的な原則を導きたいと思います。 SQL文が動的に変化する場合のSQLインジェクション対策 「間違いだらけの…」で示したように、識別子エスケープが必要な局面でそれが洩れていると脆弱性の要因になることがありますが、それは外部から指定したデータにより、SQL文の構造が変化してしまい、アプリケーションの要件にないSQL呼び出しがなされてしまうからでした。 しかし、「間違いだらけ…」の後半で示したように、識別子のエスケープだけではセキュリティ問題を防ぐことはできず、情報漏洩を招いてしまいました。外部から任意のSQL識別子を指定できることが問題という結論でした。 上記のように、アプリケー
XSSとSQLインジェクションの両方が可能なRFC5322適合のメールアドレス
メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
まとめよう、あつまろう - Togetter
