How to solve flutter web api cors error only with dart code?
It seems like CORS error is well-known issue in the web field. But I tried flutter web for the first time ever and I faced critical error. The code below worked well in app version when it was running on iOS device, but when i tested the same code on Chrome with web debugging from beta channel, it encountered CORS error. Other Stack Overflow answers explained how to solve the CORS issue with serve
FlutterからAPIアクセスする際に、XMLHttpRequest errorのエラーが出る
前提・実現したいこと Flutter(Dart)を用いて、外部APIにアクセスして情報を取得するシステムを作っています。 HotPepperのAPIから情報を取得するテストとして、ターミナルに取得した情報を表示するプログラムを実行する際にエラーが発生しました。 参考にしたサイト：https://qiita.com/abouch/items/90107b330bb126a6f742 発生している問題・エラーメッセージ await http.get(Uri.parse(url)).then((response)...の部分で、以下のエラーが発生した。 Error: XMLHttpRequest error. dart-sdk/lib/_internal/js_dev_runtime/patch/core_patch.dart 909:28 get current packages/http/s
Android 9でHTTP通信を有効にする方法
Android8以下で問題なく通信できていたアプリがAndroid9になった途端に通信NGに失敗する、という問題に直面。Android 9.0 (Pie) の仕様変更が原因でした。 何が変わった？Android 9.0では暗号化されていない接続はデフォルトで無効になります。iOSの ATS (App Transport Security) と同じような考え方ですね。 ちなみに、暗号化されていない接続を「クリアテキスト接続」と呼ぶようです。「平文」と同義ととらえればよさそう。 望ましい対応全ての通信をTransport Layer Security (TLS) に対応するのがベストプラクティス。一般的なアプリだとHTTPを使わずHTTPSにすればOK。Socketとかを使っている場合はそちらもケアしましょう。 （好ましくはないが手軽な）代替案AndroidManifest.xmlのappli
HTTPヘッダインジェクションとOSコマンドインジェクションの違いと対策方法を徹底解説！ | セキュリティ対策 | CyberSecurityTIMES
HTTPヘッダインジェクションとOSコマンドインジェクションの違いと対策方法を徹底解説！ 2020.01.06 セキュリティ対策 概要 HTTPヘッダインジェクションは、HTTPレスポンスヘッダの出力処理に関するサイバー攻撃です。この脆弱性が存在する場合、「任意のクッキーがセットされる」、「任意のURLへリダイレクトされる」などの問題が発生する可能性があります。 前提 攻撃の説明の前に、少しだけHTTPレスポンスのデータ構造についてご説明します。 データ構造の仕組みを悪用することがHTTPヘッダインジェクションになり、最低限の知識は身につけておく必要があります。 HTTPで通信した際、HTTPレスポンスは下記のような内容になります。 【HTTPレスポンスの例】 HTTP/1.1 200 OK Date: Wed, 08 Feb 2017 08:33:35 GMT Expires: -1 C
マンションのLAN内のゲートウェイが中間者攻撃してくるお話 - Qiita
来歴 私は去年、とある賃貸マンションへ入居した。 インターネットは無料で利用可能、壁の端子にLANケーブルを挿すだけ。 ただ、この物件のインターネット回線がおかしい。1日に1回くらい、Webサイトを閲覧しようとしたときに、マンションの管理会社のホームページへリダイレクトされる現象が起きる。 イメージとしてはこんな感じ。 東京の天気が表示されるべきなのに、入居者用Webページのログイン画面へリダイレクトされる。 腹が立ったので今年の5月くらいに現象を調べ、原因がわかったことで満足していたが、重い腰を上げて結果を以下の記事にして公開する。改めてGoogle先生に聞いたら、同じことで悩んでいる人がいた。 自動リダイレクトの回避方法について。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10165027165 なお、後述の図には
文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの
X-Frame-Options - HTTP | MDN
HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection Mozilla web security guidelines Mozilla Observatory HTTP アクセス制御 (CORS) HTTP
5分でできるPHPセキュリティ対策 - ぼくはまちちゃん！
こんにちはこんにちは！！ Webプログラミングしてますか！ よく「PHPはセキュリティがダメ」とか言われてるよね。 でもそれって、べつにPHPが悪いんじゃなくて、 たぶん、セキュリティとかが、まだよくわからない人が多いだけなんじゃないかな。 がんばって勉強しようと思っても、なんだか難しい理屈が並んでいたりするしね…。 なので今日は、セキュリティ対策について、 「これだけやっとけば、わりと安全になるよ」ってことを、初心者むけに、大雑把に書いてみます！ 理屈がわからなくても、最初はコピペでも、 なにもやらないより、やったほうがきっとマシになる！ 1. XSS対策 動的なものを表示するとき、全部エスケープすればokです！ (NG) あなたの名前は <?= $name ?> ですね！ ↓ (OK) あなたの名前は <?= htmlspecialchars($name, ENT_QUOTES) ?>
67. PHPファイルの応答ヘッダーに含まれるPHPバージョンを隠蔽する
ヘッダー情報からサーバーで使用しているPHPバージョンを特定されてしまい、そのバージョンのセキュリティーホールを狙った攻撃を受けてしまう可能性があります。今回は、ヘッダー情報からPHP・Apacheのバージョンを特定させない方法を紹介します。 対策がされていないサーバーへHTTPリクエストを送信し、実際にヘッダー情報を取得すると・・・ [root@localhost ~]$ telnet localhost 80 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. GET /test.php HTTP/1.0 HTTP/1.1 200 OK Date: Fri, 26 Jan 2007 12:00:00 GMT Server: Apache/2.0.59
Are there compatibility issues with SHA-2? | DigiCert FAQ
Streamlined Certificate Management and Automation: Delivering At-Scale Uptime and Availability
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
wsse認証方式 - Android Develop
Livedoorブログの開発者のブログを読んだところ Livedoorの認証はWSSE認証を使っているようです。 初めて聞きますが、どんな認証なのか調べてみました。 XML-RPC API → パスワードが生のまま送信 Atom API → WSSE方法でパスワードを暗号化 「パスワードダイジェスト」 base64(sha1(Nonce . Created . Password)) •Nonce という http リクエストごとにユニークになるように付けられた識別子(クライアント側で生成。Atom API では、通常、任意の桁数の16進数の羅列を用いる)、 •Created という日時情報(Nonce を生成した日時。2004-01-20T01:09:39Z のような形式[ISO-8601])、 •生のパスワード を連結して作った文字列を SHA1 で暗号化し、base64 化したもので
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
mod_proxy - Apache HTTP サーバ
このモジュールは Apache のプロキシ/ゲートウェイ機能を実装しています。 AJP13 (Apache JServe Protocol version 1.3), FTP, CONNECT (SSL 用), HTTP/0.9, HTTP/1.0, HTTP/1.1 のプロキシ機能を実装しています。これらのプロトコルやその他のプロトコル用の プロキシ機能を持った、他のモジュールに接続するようにも設定できます。 Apache のプロキシ機能は mod_proxy の他に、 いくつかのモジュールに分割されています: mod_proxy_http, mod_proxy_ftp, mod_proxy_ajp, mod_proxy_balancer, mod_proxy_connect です。ですから、 特定のプロキシの機能を使いたい場合は、mod_proxy と 該当するモジュールをサーバに (
Basic認証でのログアウトの仕方
Basic認証の仕組み WebのBasic認証は、予め認証が必要と設定されているURLに対するアクセス要求をWebサーバが受け取ったときに、Webサーバから認証要求の応答を返し、それに対してブラウザがログインのダイアログボックスを表示する、という手順で行われる。さらに具体的に説明すると、以下のような動作となる： ユーザがブラウザ上で、URL:http://server/hoge/を入力するか、リンクをクリックする。 ブラウザが認証が必要なURL、http://server/hoge/に対するリクエストをサーバに送る。このときのヘッダ情報は GET /hoge/ HTTP/1.0 : サーバがリクエストを受けた/hoge/というURIは、.htaccessなどにより、Basic認証を要求するように設定されており、サーバをこの情報を元にブラウザに以下の応答を返す。 HTTP/1.0 401 U
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dart/Flutter: Http request raises XMLHttpRequest error
Apache HTTP Server のエラーページに起因する HTTP ヘッダ情報漏えいの脆弱性（Scan Tech Report） | ScanNetSecurity
IPアドレスで日本国外(海外/外国)からのアクセスを制限する.htaccess CGI's