Vixual

弱點掃瞄

弱點: TLS Service Supports Weak Cipher Suite

Transport Layer Security (TLS), the successor to Secure Socket Layer (SSL), is a network protocol that encrypt communications between TLS servers (e.g., websites) and TLS clients (e.g., web browsers). Every communication is secured by a cipher suite: a combination of several algorithms working in concert. Cryptographic algorithms do not have a defined lifetime, but academics, researchers, and nation states are constantly evaluating them for weaknesses. Consensus on which algorithms are untrustworthy evolves over time, and if a communication is protected with a weak cipher suite then that communication can be altered or decrypted.

• Severity: Medium
• Risk: A TLS service was observed supporting weak cipher suites.
• Recommendation: Disable the cipher suites listed in the evidence column of the measurement.

Read more

弱點掃瞄

弱點 1: SSH Supports Weak Cipher

The SSH server is configured to support either Arcfour or Cipher Block Chaining (CBC) mode cipher algorithms. SSH can be configured to use Counter (CTR) mode encryption instead of CBC. The use of Arcfour algorithms should be disabled.

• Severity: Medium
• Risk: A weak cipher has been detected.
• Recommendation: Configure the SSH server to disable Arcfour and CBC ciphers.

弱點 2: SSH Supports Weak MAC

The SSH server is configured to support MD5 algorithm. The cryptographic strength depends upon the size of the key and algorithm that is used. A Modern MAC algorithms such as SHA1 or SHA2 should be used instead.

• Severity: Medium
• Risk: A weak Message Authentication Code (MAC) algorithm has been detected.
• Recommendation: Configure the SSH server to disable the use of MD5.

Read more

弱點掃瞄

弱點: SSL/TLS Service Supports Weak Protocol

Transport Layer Security (TLS), the successor to Secure Socket Layer (SSL), is a network protocol that encrypt communications between TLS servers (e.g., websites) and TLS clients (e.g., web browsers). Every communication is secured by a cipher suite: a combination of several algorithms working in concert. Networking protocols do not have a defined lifetime, but academics, researchers, and nation states are constantly evaluating them for weaknesses. Consensus on which protocols are untrustworthy evolves over time, and if communications are sent with a weak protocol then that communication can be altered or decrypted.

• Severity: High
• Risk: A TLS service was observed supporting weak protocols.
• Recommendation: Disable the protocols listed in the evidence column of the measurement.

Read more

弱點掃瞄

弱點: Site does not enforce HTTPS

The site responds to HTTP requests without ultimately redirecting the browser to a secure version of the page. Since the site allows plaintext traffic, a man-in-the-middle attacker is able to read and modify any information passed between the site and the user. There are a variety of situations in which an attacker can intercept plaintext traffic in a man-in-the-middle position, including but not limited to:

1. Open Wi-Fi Hotspots
2. WPA/WPA2 encrypted hot-spots where the attacker connected before the victim
3. Malicious Wi-Fi access points
4. Compromised switches and routers
5. ARP poisoning on the same wired network

It's important to remember that in many of the above situations, an attacker can not only read traffic, but also actively modify the traffic. Even if a site that does not contain sensitive information, an attacker can still inject malicious content to a user’s browser.

• Severity: High
• Risk: Site does not enforce the use of HTTPS encryption, leaving the user vulnerable to man-in-the-middle attackers (who can falsify data and inject malicious code).
• Recommendation: Any site served to a user (possibly at the end of a redirect chain) should be served over HTTPS.

Read more

fbclid 是什麼

近期 Facebook 粗爆地將用戶分享的網址加入了「fbclid」參數，藉此可以知道網頁是從 Facebook 的哪個地方分享過來的，例如:

http://www.vixual.net/blog/archives/107

經過 Facebook 分享後會變成:

http://www.vixual.net/blog/archives/107?fbclid=IwAR1nXHK4zzzPFEvJHk41Dzgew0lq5BzIoMqHPx05UVmWRQKorKan492B0h0

fbclid 參數竟然有 61 個字元，讓過去有在弄短網址的都直接破功了。

Read more

以往我都是用 Dropbox 來備份手機上的相片，但是這幾年 Dropbox 所贈送的免費空間都陸續到期了，反倒是 Google 經常會跟一些手機大廠合作，推出買新手機或平板送雲端空間的促銷活動，因此我的 Google 雲端空間已經累積到 319GB 了。

319GB 不拿來用很可惜，於是我就興起了把備份相片的空間改為 Google 相簿的念頭。

雖然 Dropbox 與 Google 相簿都是雲端備份的方案，但用起來卻是差蠻多的，尤其是刪除相片的時候要小心，免得備份檔案變成同步刪除檔案，就會欲哭無淚。於是本篇就是針對「刪除相片」功能來做比較的。

Read more

為什麼要停用 IPv6?

1. 不熟、抗拒學習
2. IPv6 也要設 IP 反解 PTR
3. Gmail 會擋沒有設 IPv6 反解的郵件

Read more

MediaWiki 預設只能上傳 png、gif、jpg、jpeg 這些圖檔，我們可以在 LocalSettings.php 編輯:

$wgEnableUploads  = false;
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg' );

加入你額外想要上傳的檔案類型 (找不到這兩行的話就自己加上去):

$wgEnableUploads  = true;
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'zip', 'pdf', 'rar' );

上面的目的是為了可以額外再上傳 zip、pdf、rar 類型的檔案。可惜事與願違，上傳 pdf 與 rar 檔都沒問是，但要上傳 zip 檔卻給我出現:

MIME 類別 "application/zip" 不是容許的檔案格式。

原來是因為 MediaWiki 有設一些副檔名的「黑名單」，剛好 zip 就在其中，設定檔在: includes/DefaultSettings.php

找到內容:

$wgMimeTypeBlacklist= array(
        # HTML may contain cookie-stealing JavaScript and web bugs
        'text/html', 'text/javascript', 'text/x-javascript',  'application/x-shellscript',
        # PHP scripts may execute arbitrary code on the server
        'application/x-php', 'text/x-php',
        # Other types that may be interpreted by some servers
        'text/x-python', 'text/x-perl', 'text/x-bash', 'text/x-sh', 'text/x-csh',
        # Client-side hazards on Internet Explorer
        'text/scriptlet', 'application/x-msdownload',
        # Windows metafile, client-side vulnerability on some systems
        'application/x-msmetafile',
        # A ZIP file may be a valid Java archive containing an applet which exploits the
        # same-origin policy to steal cookies
        'application/zip',
);

將「'application/zip',」刪除即可。

至於上傳 zip 檔未來的後果會是如何...這我就不能預料了。

「iframe (內置框架)」是用來在網頁中的特定位置嵌入另一個網頁。目前 Facebook、Google+、Twitter...等用來在網頁上顯示社群內容的社群元件，幾乎都是以 iframe 實作出來的。

原本框架是一種很好的應用，但如果是自己辛苦製作的網頁被別人的網站以 iframe 嵌入，因而出現在別人的網站裡，成為別人網站的一部份!!這種感覺就像是自己的心血被別人整碗捧走一樣!!

導回自已網站的方法

方法 1

於網頁的原始碼加入以下 Script:

<script type="text/javascript">
if( top.location != document.location ){
	top.location.href = document.location.href;
}
</script>

以上的 Script 會檢查瀏覽器最上層視窗的網址是否與目前網頁的網址一致，如果不一致，則把最上層視窗的網址改為目前網頁的網址，就醬。

方法 2 (反制辦法)

於網頁的原始碼加入以下 Script:

<script type="text/javascript">
if( top.location != document.location ){
	document.write("<h1 style='color:#FF0000'>未經授權嵌入別人的網頁是可恥的行為!!</h1>(<a href='"+document.location+"' target='_blank'>原站網址</a>)");
}
</script>

以上的 Script 會檢查瀏覽器最上層視窗的網址是否與目前網頁的網址一致，如果不一致，就顯示:

未經授權嵌入別人的網頁是可恥的行為!!
(原站網址)

我比較不喜歡與人家互嗆，所以我通常是用「方法 1」啦!

2020/12/30 更新:

Google 通知，將於 2021 年初停止透過西聯匯款支付款項，所以本網頁的教學大概也沒什麼用了。
如要繼續收到 Google 支付的款項，你必須登入自己的帳戶，然後新增或選取其他收款方式 (匯款或支票)。

之前的內容:

Google AdSense

約莫等了半年，終於又收到了一筆 Google AdSense 的廣告收入了，算是農曆過年前的一個小小小紅包。

在台灣，AdSense 的用戶可以使用「西聯匯款」來進行收款，目前台灣有支援西聯匯款的銀行有京城銀行、大眾銀行與元大銀行。

我是使用「京城銀行」，這個有點陌生的銀行。它的「網路西聯匯款」服務可以直接將我的 AdSense 廣告收益從美金轉為台幣存入我的銀行帳戶，並且不收取任何手續費、不用等待，但是會有匯損的問題。

不過我今天要操作收款時，發現做為「匯款人」的 Google 的身份又改變了! 原本的身份「Google Ireland Ltd. (愛爾蘭)」，更早之前是「Google Inc. (美國)」，現在的匯款人身份則為「Google Asia Pacific Pte. Ltd. (新加坡)」!

這個付款人的資訊會影響我們能否正常收款，不過沒關係，下面會教你如何識別付款者的身份。

Read more