有 老鼠 webgl 碰 上 麻煩 了

• 首頁
• 電腦教學
• [教學] 解決 Google Chrome 瀏覽器跳出「有老鼠！WebGL 碰上麻煩了」錯誤訊息

最近這陣子使用 Google Chrome 瀏覽器，逛網頁的時候會無預警跳出「有老鼠！WebGL 碰上麻煩了。」錯誤訊息，尤其是 Facebook 臉書與蘋果 Apple 網頁發生機率特高，有些時候畫面還會變全黑或灰色情況，頁面整個卡住無法瀏覽情況，雖然說按忽略或重新載入就能正常顯示網頁，但常常遇到對於效率變差情況也不是好現象，爬文後才知道原來是 WebGL 繪圖系統問題，有多種解決方式可以使用，內文有完整圖文教學做搭配，如有遇到這情況朋友不妨試試。

上圖就是常見「有老鼠！WebGL 碰上麻煩了」錯誤畫面，可能導致 Facebook 卡住或是 YouTube 影片沒辦法觀賞情況，經過查詢這與採用架構在 OpenGL ES2.0 上面提供 API 給瀏覽器使用 3D 繪圖技術 WebGL 有關，然而這個 Bug 可能使得駭客竊取電腦繪圖晶片記憶體資料，進而導致個資被竊取情況，正常情況建議關閉此功能或未採用 WebGL 瀏覽器為上上策。

修復教學：

首先確保 Google Chrome 瀏覽器已經更新到最新版本。

接著於 Chrome 瀏覽器網址列輸入 chrome://flags/，找到 WebGL 將它變更為 Disabled。

最後再到設定 -> 進階 "在可用時使用硬體加速" 將此選項給關掉，並重新啟動 Chrome 或是重開機就可以了！！

此外也有國外熱心網友錄製操作影片，你也可以依樣畫葫蘆跟著做，我想就能輕鬆解決這問題啦。

有老鼠!WebGL碰上麻煩了_問題解決

網址列輸入chrome://flags/

找到 WebGL 2.0   ---->  Set 已停用  並重啟Chrome(or重開機)

ASP.NET WebService(二)_三種存取方式介紹_webmethod屬性大致介紹

很久以前曾整理過一篇xml webservice部落格文章 https://coolmandiary.blogspot.com/2017/11/web-service.html  可以得知用於應用程式整合、B2B整合和跨防火牆的通訊 如今因為又看到其他文章跟在實際專案中再次見面 因此想再加深補充實務上的經驗分享當筆記 在此之前先溫顧一下 在.NET WebService中共分為三種存取途徑 1.EndPoint (SOAP): 也就是比較常在市面上基礎教授書籍中講的URI location  會直接條列出web service所包含的一系列方法及方法描述、Class描述 是XML based的message template，是Browser跟WebService之間溝通收發的橋樑。 實際案例: http://www.webxml.com.cn/WebServices/WeatherWS.asmx 2.Disco(Web Service Discovery):用於指向web服務位置 Disco 的用途就像電話簿和搜尋引擎網站一樣，提供資訊分類以及尋找的服務，讓我們能方便迅速找到所需的 Web Services。 其運作原理是，當開發人員將一個 Web Service 設計完成之後，可以將它登錄到一個集中的地方，其他人就可以向這個集中地查詢找到需要的服務。這個登錄－查詢的機制只要就是依靠 UDDI（Universal Description, Discovery and Integration） 來達成。 (備註:在不知道哪裡有你需要的 Web Services情境下起到作用。) 實際案例: http://www.webxml.com.cn/WebServices/WeatherWS.asmx?disco 3.WSDL(Web Services Description Language): 用於描述webservice服務定義的方法、屬性、Binding的協定、Port、URI 當在網路上找到一個 Web Service，如何知道怎樣使用？有哪些服務、方法可以呼叫？ 要傳遞對應哪些參數？ (備註:是在你已經確定要使用某個 Web Service 並且知道其網址的情形下才有用) 實際案例: http://www.webxml.com.cn/WebServices/Wea

經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients

近期新加入的功能code剛好也被CheckMarx掃出高風險部分的程式碼漏洞 我也踏到這個Issue啦 Cross Site Scripting(XSS)  第一種.Stored XSS 高風險 CheckMarx掃碼報告給的說明[Stored XSS] ============================================================ 風險: 攻擊者可以利用合法存取應用程式提交資料到資料庫。 當另一個使用者隨後存取該資料，網頁可能會被改寫且惡意腳本可能會被啟動。 發生原因: 從資料庫中的資料建立網頁。資料直接嵌入至HTML的頁面，利用瀏覽器顯示。 資料可能源自於其他使用者的輸入。 如果資料包含HTML片段或Javascript，使用者無法分辨是否為預期的頁面。 該漏洞主因為未先對嵌入資料庫中的資料進行編碼(Encode) 來預防瀏覽器將其當為HTML的格式而非純文字。 如何避免: 1.驗證所有資料，無論其來源為何。驗證應基於白名單：僅接受預定結構的資訊，而不是拒絕不良的樣式(Patterns)。  應確認：  ● 資料型態  ● 大小  ● 範圍  ● 格式  ● 期望值  2. 驗證無法取代編碼. 輸出嵌入之前，不論其來源， 將所有動態資料進行編碼. 編碼方式應該是上下文相關的. 例如: ● HTML內容使用HTML的編碼方式  ● HTML編碼特性是將資料輸出到特性的值 ● JavaScript的編碼方式為伺服器產生的Javascript  3.考慮使用ESAPI的編碼庫，或它的內置功能。對於舊版的ASP.NET，請考慮使用AntiXSS.  4.在HTTP類型對應的表頭， 明確定義整個頁面的字元編碼.  5. 設置 httpOnly 標誌於會期資訊，以防止利用XSS來竊取資訊. ============================================================ 這裡報告描述是指我對傳進來字串參數直接拋給DAL處裡的類別執行查詢 這裡缺乏對輸入進來的字串參數做一些查檢判斷 也建議在帶入時對參數也做一些html encode處理 這裡用AntiXSS來Encode 第二種.Reflected XSS All Clients 高風險 CheckMarx掃碼報告給的說明[Reflecte

經得起原始碼資安弱點掃描的程式設計習慣培養(五)_Missing HSTS Header

接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 最近又遇到被若安掃描到高風險要修正的程式碼啦.... 一看這還真是搞不懂該怎麼修呢 HSTS(HTTP Strict Transport Security)  主要是一份國際標準規格 (RFC 6797) 的網際網路瀏覽安全機制， 用於宣告瀏覽器與伺服器之間通訊方式必須強制採用 TLS/SSL 加密通道。 只要從伺服器端送出一個 Strict-Transport-Security 標頭 (Header) 給瀏覽器，即可告知瀏覽器於未來的某段時間內一律使用 SSL 來和該網站連接 (設定可涵蓋所有子域名網站)， 一旦發生憑證失效情況，使用者將無法再瀏覽該網站，如此一來便可大幅減少中間人攻擊的問題發生。 再更白話一點 HSTS Header 就是負責將 http 強制轉為 https CheckMarx掃碼報告給的說明 ============================================================ 風險: 如果web config沒有設置HSTS表頭、"max-age"(有效期)不足一年， 或沒有設定"includeSubDomains"(包含所有子網域)，可能會使用戶容易遭受中間人攻擊。 發生原因: 許多使用者只要在瀏覽器的網址列輸入網域名稱(Domain Name)即可瀏覽網站， 並沒有輸入協定(Protocol)的名稱。 瀏覽器會自動假設使用者使用的是HTTP協定而不是有加密機制的HTTPS協定。 在第一次發出前往特定網站的請求時，攻擊者可以執行中間人攻擊並將用戶轉址到