回車換行符 crlf 那點事 阿新 • • 發佈：2019-01-04 簡介 編輯 CRLF的意思 就是回車(CR, ASCII 13, \r) 換行(LF, ASCII 10, \n)。 換行在有的ASCII碼錶也用newline（簡nl）來進行表示,這裡的lf是line feed的概念，意思是一樣的。 這兩個ACSII字元不會在螢幕有任何輸出，但在Windows中廣泛使用來標識一行的結束。而在Linux/UNIX系統中只有換行符。 CRLF命令 它表示鍵盤上的"Enter"鍵(可以用來模擬回車鍵)。 CRLF注入 就是說黑客能夠將CRLF命令注入到系統中。它不是系統或伺服器軟體的漏洞，而是網站應用開發時，有些開發者沒有意識到此類攻擊存在的可能而造成的。 針對這個漏洞黑客能夠做什麼？ 就算黑客發現網站存在CRLF注入，他們仍然受到應用結構和這個缺陷的嚴重程度的限制。 對有些站點它將非常嚴重，而有些站點它只是很小的bug。 HTTP Header CRLF Injection 許多 網路協議，包括HTTP也使用CRLF來表示每一行的結束。這就意味著使用者可以通過CRLF注入自定義HTTP header，導致使用者可以不經過應用層直接與Server對話。 HTTP header的定義就是基於這樣的"Key: Value"的結構，用CRLF命令表示一行的結尾。 "Location:"頭用來表示重定向的URL地址，"Set-Cookie:"頭用來設定cookies。 如果使用者的輸入經過驗證，其中存在CRLF的字元就可以被用來達到欺騙的目的。 實際應用 編輯 CRLF注入攻擊並沒有像其它型別的攻擊那樣著名。但是，當對有安全漏洞的應用程式實施CRLF注入攻擊時，這種攻擊對於攻擊者同樣有效，並且對使用者造成極大的破壞。讓我們看看這些應用程式攻擊是如何實施的和你能夠採取什麼措施保護你的機構。 CRLF的含義 是“carriage return/line feed”，意思就是回車。這是兩個ASCII字元，分別排在第十三和第十位。CR和LF是在計算機終端還是電傳印表機的時候遺留下來的東西。電傳打字機就像普通打字機一樣工作。在每一行的末端，CR命令讓列印頭回到左邊。LF命令讓紙前進一行。雖然使用捲紙的終端時代已經過去了，但是，CR和LF命令依然存在，許多應用程式和網路協議仍使用這些命令作為分隔符。 攻擊者在搜尋安全漏洞的時候沒有忽略很少使用的CRLF。攻擊者可以通過在一段資料中加入CRLF命令來改變接受這個資料的應用程式處理這個資料的方式，從而執行CRLF注入攻擊。 CRLF攻擊 最基本的例子包括向 記錄檔案中增加偽造的記錄。也就是說，有安全漏洞的應用程式把一個使用者輸入的內容寫到系統記錄檔案中。攻擊者可以提供如下輸入內容: Testing123MYSQL DATABASE ERROR: TABLE CORRUPTION 當系統管理員在早上檢視他的紀錄時，他可能會用很多時間排除一個根本就不存在的故障。狡猾的攻擊者在攻擊系統的另一部分時，可以使用這種特洛伊木馬分散管理員的注意力。 想像一下，一個應用程式收到使用者輸入的一個檔名，然後對那個檔案執行一個指令，如“ls -a .”。如果這個應用程式存在CRLF安全漏洞，攻擊者就可以輸入這樣的內容: File.txtrm -rf / 這個有安全漏洞的應用程式就會執行這個命令“ls -a File.txt”，然後再執行這個命令“rm -rf /”。如果這個應用程式是一個根程式，這可能就是它執行的最後一個命令，因為在根分割槽的全部檔案都被刪除了。 考慮使用一種CRFL注入攻擊暴露使用一種基於網路的匿名電子郵件系統的某個人的電子郵件地址。那個電子郵件系統的工作方式可能是這樣的:電子郵件的傳送者用他們的電子郵件地址、資訊主題和資訊本身填寫一個表格。當這個表格遞交到網路伺服器上的時候，網路伺服器把這個表格轉換為一個SMTP電子郵件，並且傳送給收件人。傳送者永遠不會看到收件人的電子郵件地址。這個地址只有伺服器知道。 如果這個應用程式存在CRLF攻擊安全漏洞，電子郵件的發件人可以通過建立下面這樣的一行主題來破壞收件人的匿名性: Subject: Peekaboo, I see youBcc: 當有安全漏洞的應用程式得到這個資料的時候，它向這個郵件的檔案頭增加一個不需要的行，建立一個傳送到發件人郵件地址的這封郵件的盲送副本。在這個副本中，“To:”地址是看不到的，因此把收件人的郵件地址暴露給傳送者。 避免攻擊的方法 使用良好的程式設計技術能夠避免包括CRLF攻擊在內的注入攻擊。要使你的應用程式不受CRLF注入攻擊，需要你保持與防禦SQL注入攻擊等其它型別的注入攻擊一樣的警惕性:永遠不要相信輸入的內容!在你控制範圍以外的任何來源的輸入內容都必須要進行檢查，在你的應用程式對資料執行操作之前，任何不符合預期的資料型別的字元都要刪除。例如，如果你期待著一個電子郵件主題行，這個資料中的所有的字元都應該是字母、數字和標點符號。如果你的應用程式期待著一個檔名，這個資料中只能包含合法地在檔名中使用的字元。如果程式設計師在這兩個例子的情況下簡單地過濾掉CR和LF字元，這個攻擊就失敗了。 使用者輸入是“壞字元”的一個來源。但是，你不要忘記檢查你從來沒有編寫過的其它程式輸入的內容。在許多情況下，攻擊者可以把一個注入攻擊從一個有漏洞的應用程式轉移到一個基本的例行程式中。程式設計師不會檢查基本的例行程式中的資料，因為那裡的資料不是直接來自於使用者。你要把任何你不能跟蹤到可信賴的來源的資料都當作被感染的資料。這樣，你就安全了
