2017年03月31日

jQuery備忘録

ちょっと最近のお気に入りはjQueryです。
いろいろ動きが作れるとおもしろいやねぇ。プラグインもどっさりあるし。

ということで、メモをぺたぺた


jQueryでvalidation
https://jqueryvalidation.org/ (柔軟だが記述に癖あり)

駆け出しプログラマの備忘録
【JavaScript】【jquery】jquery.validate.jsの基本的な使い方
http://yu-ya4.hatenablog.com/entry/2015/07/04/130627

JavaScript Library Archive
簡単にフォームの入力チェックが行えるjquery.validate.js
http://javascript.webcreativepark.net/library/jquery_validate


https://github.com/posabsolute/jQuery-Validation-Engine (えらいかんたん、名前が似ているので注意)

こちらの解説が詳しいです

AllAbout デジタル
フォームの入力内容をリアルタイムにチェックする方法


偉大なる先人の方々に感謝感謝。
posted by koteitan at 16:17| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2017年03月15日

JSON.parse()が厳密で辛い・・。

stringfy()してから渡せばちゃんとparseしてくれるが、
どこが間違っているのかわからない・・・。orz

素直にjsonicやjackson、Gson使えよ、って話なんだが、
ただのテスト用servletでわざわざclass定義するのもなぁ・・。
pythonでやれればいいんだが。
続きを読む
posted by koteitan at 16:19| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2017年03月02日

CVE-2016-8743  Apache HTTP Request Parsing Whitespace Defects

リクエスト中にあるCRをスペースと解釈することを悪用してスマグリング攻撃をしかけたり、とかの問題。
歴史的な問題から、HTTPリクエストの解釈はウルトラふんわりしなきゃならなかった。
HTTP/1.1もhttp/1.1でもOKにするとか、スペースの数とかね。

もっと詳しくはRFCを熟読してもらうとして、(https://tools.ietf.org/html/rfc7230#section-3.1.1
この解釈をきっちり行うことで、脆弱性を防ぐ、というわけだね。


     Apache HTTP Server, prior to release 2.4.25, accepted a broad pattern of unusual whitespace patterns from the user-agent, including bare CR, FF, VTAB in parsing the request line and request header lines, as well as HTAB in parsing the request line. Any bare CR present in request lines was treated as whitespace and remained in the request field member "the_request", while a bare CR in the request header field name would be honored as whitespace, and a bare CR in the request header field value was retained the input headers array. Implied additional whitespace was accepted in the request line and prior to the ':' delimiter of any request header lines.

    RFC7230 Section 3.5 calls out some of these whitespace exceptions, and section 3.2.3 eliminated and clarified the role of implied whitespace in the grammer of this specification. Section 3.1.1 requires exactly one single SP between the method and request-target, and between the request-target and HTTP-version, followed immediately by a CRLF sequence. None of these fields permit any (unencoded) CTL character whatsoever. Section 3.2.4 explicitly disallowed any whitespace from the request header field prior to the ':' character, while Section 3.2 disallows all CTL characters in the request header line other than the HTAB character as whitespace.

    These defects represent a security concern when httpd is participating in any chain of proxies or interacting with back-end application servers, either through mod_proxy or using conventional CGI mechanisms. In each case where one agent accepts such CTL characters and does not treat them as whitespace, there is the possiblity in a proxy chain of generating two responses from a server behind the uncautious proxy agent. In a sequence of two requests, this results in request A to the first proxy being interpreted as requests A + A' by the backend server, and if requests A and B were submitted to the first proxy in a keepalive connection, the proxy may interpret response A' as the response to request B, polluting the cache or potentially serving the A' content to a different downstream user-agent.

    These defects are addressed with the release of Apache HTTP Server 2.4.25 and coordinated by a new directive;

        HttpProtocolOptions Strict

    which is the default behavior of 2.4.25 and later. By toggling from 'Strict' behavior to 'Unsafe' behavior, some of the restrictions may be relaxed to allow some invalid HTTP/1.1 clients to communicate with the server, but this will reintroduce the possibility of the problems described in this assessment. Note that relaxing the behavior to 'Unsafe' will still not permit raw CTLs other than HTAB (where permitted), but will allow other RFC requirements to not be enforced, such as exactly two SP characters in the request line.

    Acknowledgements: We would like to thank David Dennerline at IBM Security's X-Force Researchers as well as Régis Leroy for each reporting this issue.
    Reported to security team: 10th February 2016
    Issue public: 20th December 2016
    Update Released: 20th December 2016
    Affects: 2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1, 2.2.31, 2.2.29, 2.2.27, 2.2.26, 2.2.25, 2.2.24, 2.2.23, 2.2.22, 2.2.21, 2.2.20, 2.2.19, 2.2.18, 2.2.17, 2.2.16, 2.2.15, 2.2.14, 2.2.13, 2.2.12, 2.2.11, 2.2.10, 2.2.9, 2.2.8, 2.2.6, 2.2.5, 2.2.4, 2.2.3, 2.2.2, 2.2.0



Security risks of Unsafe

Users are strongly cautioned against toggling the Unsafe mode of operation, particularly on outward-facing, publicly accessible server deployments. If an interface is required for faulty monitoring or other custom service consumers running on an intranet, users should toggle the Unsafe option only on a specific virtual host configured to service their internal private network.
 HttpProtocolOptions Unsafe で元通りの解釈になるようなので、この修正を適用したらアプリがエラー吐きまくりでござる、\(^o^)/
 になったら、十分に安全を確認(悪意が入らないかどうかを精査)した上で、解除するってのも有りなんだろうけど。
 ま、自己責任で。セキュリティの観点からいえばアプリを直せ、になるからねぇ。
続きを読む
posted by koteitan at 13:44| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2017年02月23日

IISのエラーログの場所

(;´Д`) IISなんか20年前ぐらいに触っただけなんだが、超進化しとるな・・。

apacheとかだとデフォルトならAccessLogと同じ場所に出力されるエラーログも
やっぱり独自路線のIIS。

おもくそ探して このフォーラムのdeeplfoさんのコメ

OK, seems like I found my answer, from here: http://support.microsoft.com/default.aspx?scid=kb;en-us;820729

"The HTTP API creates a subfolder HTTPERR in the specified folder, and then stores the log files in the subfolder. This subfolder and the log files receive the same permission settings. The Administrator and Local System Accounts have full access. Other users do not have access."

So, it seems that the HTTP API uses the root path of the logging folder specified in the IIS logging configuration and in there it creates the HTTPERR directory and sticks all the httperrxxx files there. 

つまり、ここ


んで、デフォルトやと、

%SystemRoot%\System32\LogFiles\HTTPERR 以下

アクセスログと同じ場所でええやん、と思うんだがここはやっぱり独自路線やなぁ・・。
変更もレジストリっぽいし。


こちらにも詳しく記事がありました。
puti se blog 〜   IISのエラーログはどこにあるのか?エラーログのパス。


続きを読む
posted by koteitan at 14:00| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2017年02月22日

HTML5でのストリーミングについて

このスライドがすごくよくまとめられていてよかった。



普及率、馬鹿にできないよね。
続きを読む
posted by koteitan at 16:55| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2017年02月17日

HPリニューアル

まぁ、どうせだれも見ちゃいないがね。(´・ω・`)

HTML5とjQueryを最近は勉強しているので、
練習がてらにやってみました。
面白いですね、jQuery。

ここいらの本で勉強しました。



posted by koteitan at 21:53| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2017年02月14日

Apache de UserDir

本日のドツボ

1. loadmodule がコメントのままだった

2.ユーザーのhome が 0700だった

orz

ここの記事の事象と同じ。

ユーザディレクトリ公開時に「403 Forbidden」
続きを読む
posted by koteitan at 17:23| Comment(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2017年02月10日

TicketBleed (CVE-2016-9244)

HeartBleed にもじったのかなー。

SSLのTicketが有効な場合にのみ31バイト分の未初期化メモリが見えてしまうという脆弱性。
クリアしていないメモリ=なんらかのセキュア情報を含む(可能性が高い)ので、
えらいこっちゃというわけですな。


チケットについてはこちらが詳しい

TLSセッション再開 (session resumption) のしくみ

TLS Session Ticketの動作をtsharkでなんとなく覗きみる

RFCのリンクもはっておきます。


F5社のページ

発見者のページ
※確認用のユーティリティがおいてありますが、あくまで自己責任で!


続きを読む
posted by koteitan at 11:18| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2016年10月05日

CVE-2016-2776(Bind AssertionFailure)

ちょっと前に騒がれていたが、PoCが出たことで再燃した。
なんせ1パケットで死ぬから、効率よくDosできちゃう。

素RHEL6で試してみたが、即死したぞ。

BindCrash.png

PoCについての言及は避けます。

https://access.redhat.com/security/cve/cve-2016-2776
https://www.ipa.go.jp/security/ciadr/vul/20160929-bind.html
https://jprs.jp/tech/security/2016-09-28-bind9-vuln-rendering.html

速やかにアップデートしましょう。
企業だと回帰検証とかあーだこーだで機動力ないとつらいとこだがねぇ・・。
posted by koteitan at 23:34| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2013年05月29日

[セキュリティ]これはひどい(;´Д`)

robots.txt の設定がクソまじめすぎて噴いた。
ピュアハートなのだろう。

それは robots.txt の問題じゃなくて...
http://hyper-text.org/archives/2013/05/robotstxt_is_not_bad.shtml

Drupalについては詳しく知らないけど、オープンソースなCMSなんでしょう。
WebサイトやHTMLの構造に詳しくなくてもポータルサイトを運営したりと利用者からすれば
便利なものではあるんだが、構築ぐらいはプロに頼まないとなぁ・・。
オープンソース=タダ=安い が先行してると感じたよ。

CVVの保存とかシステム設計自体もイケてないっぽいしなー。
インシデント発生から発表までの遅さとかから運営会社自体イケてないのはわかるが
構築した業者も相当だと思ったなぁ。
まぁ、セキュリティの会社に頼むと高いからな。安く済ませたいのはわかるけど
高いのには高い理由があるし、その逆で安いのは安い理由があるんだよなぁ。
流出したIDの持ち主さんや、不正利用されたショップ様がかわいそうだぜ。

それにしても、この会社の杜撰さを叩くのは私もわかるけど、
一番悪いのはIDを盗んだ連中と不正利用している連中だよな。
鍵がかかっていなかったら盗んでよい、なんてことはないわけで。
詐欺とかもそうで、だまされるやつが悪いんじゃなくて、だます方が悪いんだしね。


posted by koteitan at 17:50| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2011年04月27日

[websphere]手動式記憶吐出

ハンドでヒープをテイクアウトする方法

Infocenterに書いてあるけどな。
jython版はちょっと珍しい

Manually generating heap dump
You can use the WSAdmin script to generate heapdump for the JVM. Use this Jython script to do that

def generateHeapDump(serverName):
serverJVM = AdminControl.queryNames("type=JVM,process="+serverName+",*")
print serverJVM
AdminControl.invoke(serverJVM,"generateHeapDump")


generateHeapDump("server1")


引用元
http://wpcertification.blogspot.com/2009/07/manually-generating-heap-dump.html

thanks!
posted by koteitan at 15:44| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2011年03月09日

シャノンの標本定理

まぁ、ややこしい説明は学問だから、
結論だけ。工学だからな。

原信号に含まれる最大周波数成分を f とすると、2f よりも高い周波数 fs で標本化した信号は、低域通過(ローパス)フィルターで高域成分を除去することによって原信号を完全に復元することができる

もっとかみ砕く。

サンプリング周期=原信号の最大周波数×2

四間、もとい試験に出るのはサンプリングしたら何バイトやねん?系な問題じゃろうて。
posted by koteitan at 13:19| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

シュミットトリガ

シュミットトリガ

難しく言う
入力のノイズを除去する。少々のゆらぎでは反応しない。
ヒステリシス特性を持つ一種のメモリとも考えられる。

わかりやすくいう
鈍感

実際反応が遅れるので、クロック入力などには向かない。

http://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%A5%E3%83%9F%E3%83%83%E3%83%88%E3%83%88%E3%83%AA%E3%82%AC
http://ja.wikipedia.org/wiki/%E3%83%92%E3%82%B9%E3%83%86%E3%83%AA%E3%82%B7%E3%82%B9
http://aitem-lab.com/tc_interface1_001%281%29.html

posted by koteitan at 12:39| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2011年03月06日

MTBFの合成(≒信頼率の合成)

計算問題落とすのがイチバン響くからなー。
MTBFと信頼率(故障率)の関係が分かっていれば、計算するだけになりますな。

信頼率の計算はまぁ確率の計算なんで、直列だと掛け算で
並列だと余事象だっけ、(1-a)(1-b)みたいな式。(≒故障率の掛け算)

故障率とMTBFは逆数の関係に近似できるので MTBF=1/故障率 故障率=1/MTBF
信頼率は1−故障率

例題
MTBFがそれぞれ2000時間、5000時間のシステムABが直列に接続されている。
ここに、システムCを接続し、全体のMTBFを1000時間以上にするにはシステムCの
MTBFを何時間以上にすればよいか?

なーんてカンジででる。
信頼率で置き換えれば余裕で

(1-1/2000)(1-1/5000)(1-1/x)=1-1/1000

計算面倒だが、解くと 3329.89 

試験用でこんな電卓必要な式はやっとれんので、
続きに別解答。続きを読む
posted by koteitan at 16:21| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

バグ埋め込み法

なんやそれ・・・。目から鱗。
使っている現場なんかあるのかな。典型的な試験用の知識な気がする。
埋め込まなくても無数にあるので(ゲフンゲフン
テスト件数に対するバグ件数が異常に少ないとき、逆に
「これちゃんとテストしたんか!」というのはあるかもしれんがなぁ。

バグ埋め込み法
 故意にバグを埋め込み、その埋め込んだバグの発見数から
 潜在バグ数を推定するもの。
 埋め込みバグの発見確率と潜在バグの発見確率が同じという仮定がある。

問題にでてくる場合は、計算問題で
 バグ埋め込み法を用いて20個のバグを埋めんだ。
 これまでのテストで発見されたバグ数は40で、そのうち埋め込みバグは10だった。
 あと何件のバグを発見すればテスト終了と判断してよいか・・?

という具合ででる。

発見率が同じという仮定があるので、

埋め込み総数:見つかった埋め込み数=潜在バグ総数:発見された数

という式が成り立つ。

 あと何件のという問いなら、埋め込みも含んだ数になるので、注意が必要だ。
この例題の場合だと
 20:10=x:40 x=80
 80−40=40 A.あと40件(内訳 埋10、潜30)

というからくり。

しかしググってみても試験の解答とか解説しか出てこんぜ・・?
posted by koteitan at 14:12| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする