javacc攻擊代碼 java dos攻擊

怎么樣才能寫出安全的Java代碼？不被黑客攻擊？

在本文中，我們討論了對付 13 種不同靜態(tài)暴露的技巧。對于每種暴露，我們解釋了不處理這些安全性問題所造成的影響。我們還為您推薦了一些準則，要開發(fā)不受這些靜態(tài)安全性暴露威脅的、健壯且安全的 Java 應(yīng)用程序，您應(yīng)該遵循這些準則。一有合適的時機，我們就提供代碼樣本（既有暴露的代碼也有無暴露的代碼）。

作為一家“創(chuàng)意+整合+營銷”的成都網(wǎng)站建設(shè)機構(gòu)，我們在業(yè)內(nèi)良好的客戶口碑。創(chuàng)新互聯(lián)公司提供從前期的網(wǎng)站品牌分析策劃、網(wǎng)站設(shè)計、成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、創(chuàng)意表現(xiàn)、網(wǎng)頁制作、系統(tǒng)開發(fā)以及后續(xù)網(wǎng)站營銷運營等一系列服務(wù)，幫助企業(yè)打造創(chuàng)新的互聯(lián)網(wǎng)品牌經(jīng)營模式與有效的網(wǎng)絡(luò)營銷方法,創(chuàng)造更大的價值。

對付高嚴重性暴露的技巧

請遵循下列建議以避免高嚴重性靜態(tài)安全性暴露：

限制對變量的訪問

讓每個類和方法都成為 final，除非有足夠的理由不這樣做

不要依賴包作用域

使類不可克隆

使類不可序列化

使類不可逆序列化

避免硬編碼敏感數(shù)據(jù)

查找惡意代碼

限制對變量的訪問

如果將變量聲明為 public，那么外部代碼就可以操作該變量。這可能會導(dǎo)致安全性暴露。

影響

如果實例變量為 public，那么就可以在類實例上直接訪問和操作該實例變量。將實例變量聲明為 protected 并不一定能解決這一問題：雖然不可能直接在類實例基礎(chǔ)上訪問這樣的變量，但仍然可以從派生類訪問這個變量。

清單 1 演示了帶有 public 變量的代碼，因為變量為 public 的，所以它暴露了。

清單 1. 帶有 public 變量的代碼

class Test {

public int id;

protected String name;

Test(){

id = 1;

name = "hello world";

}

//code

}

public class MyClass extends Test{

public void methodIllegalSet(String name){

this.name = name; // this should not be allowed

}

public static void main(String[] args){

Test obj = new Test();

obj.id = 123; // this should not be allowed

MyClass mc = new MyClass();

mc.methodIllegalSet("Illegal Set Value");

}

}

建議

一般來說，應(yīng)該使用取值方法而不是 public 變量。按照具體問題具體對待的原則，在確定哪些變量特別重要因而應(yīng)該聲明為 private 時，請將編碼的方便程度及成本同安全性需要加以比較。清單 2 演示了以下列方式來使之安全的代碼：

清單 2. 不帶有 public 變量的代碼

class Test {

private int id;

private String name;

Test(){

id = 1;

name = "hello world";

}

public void setId(int id){

this.id = id;

}

public void setName(String name){

this.name = name;

}

public int getId(){

return id;

}

public String getName(){

return name;

}

}

讓每個類和方法都為 final

不允許擴展的類和方法應(yīng)該聲明為 final。這樣做防止了系統(tǒng)外的代碼擴展類并修改類的行為。

影響

僅僅將類聲明為非 public 并不能防止攻擊者擴展類，因為仍然可以從它自己的包內(nèi)訪問該類。

建議

讓每個類和方法都成為 final，除非有足夠的理由不這樣做。按此建議，我們要求您放棄可擴展性，雖然它是使用諸如 Java 語言之類的面向?qū)ο笳Z言的主要優(yōu)點之一。在試圖提供安全性時，可擴展性卻成了您的敵人；可擴展性只會為攻擊者提供更多給您帶來麻煩的方法。

不要依賴包作用域

沒有顯式地標注為 public、private 或 protected 的類、方法和變量在它們自己的包內(nèi)是可訪問的。

影響

如果 Java 包不是封閉的，那么攻擊者就可以向包內(nèi)引入新類并使用該新類來訪問您想保護的內(nèi)容。諸如 java.lang 之類的一些包缺省是封閉的，一些 JVM 也讓您封閉自己的包。然而，您最好假定包是不封閉的。

建議

從軟件工程觀點來看，包作用域具有重要意義，因為它可以阻止對您想隱藏的內(nèi)容進行偶然的、無意中的訪問。但不要依靠它來獲取安全性。應(yīng)該將類、方法和變量顯式標注為 public、private 或 protected 中適合您特定需求的那種。

使類不可克隆

克隆允許繞過構(gòu)造器而輕易地復(fù)制類實例。

影響

即使您沒有有意使類可克隆，外部源仍然可以定義您的類的子類，并使該子類實現(xiàn) java.lang.Cloneable。這就讓攻擊者創(chuàng)建了您的類的新實例?？截惉F(xiàn)有對象的內(nèi)存映象生成了新的實例；雖然這樣做有時候是生成新對象的可接受方法，但是大多數(shù)時候是不可接受的。清單 3 說明了因為可克隆而暴露的代碼：

清單 3. 可克隆代碼

class MyClass{

private int id;

private String name;

public MyClass(){

id=1;

name="HaryPorter";

}

public MyClass(int id,String name){

this.id=id;

this.name=name;

}

public void display(){

System.out.println("Id ="+id+"

"+"Name="+name);

}

}

// hackers code to clone the user class

public class Hacker extends MyClass implements Cloneable {

public static void main(String[] args){

Hacker hack=new Hacker();

try{

MyClass o=(MyClass)hack.clone();

o.display();

}

catch(CloneNotSupportedException e){

e.printStackTrace();

}

}

}

建議

要防止類被克隆，可以將清單 4 中所示的方法添加到您的類中：

清單 4. 使您的代碼不可克隆

public final Object clone()

throws java.lang.CloneNotSupportedException{

throw new java.lang.CloneNotSupportedException();

}

如果想讓您的類可克隆并且您已經(jīng)考慮了這一選擇的后果，那么您仍然可以保護您的類。要做到這一點，請在您的類中定義一個為 final 的克隆方法，并讓它依賴于您的一個超類中的一個非 final 克隆方法，如清單 5 中所示：

清單 5. 以安全的方式使您的代碼可克隆

public final Object clone()

throws java.lang.CloneNotSupportedException {

super.clone();

}

類中出現(xiàn) clone() 方法防止攻擊者重新定義您的 clone 方法。

使類不可序列化

序列化允許將類實例中的數(shù)據(jù)保存在外部文件中。闖入代碼可以克隆或復(fù)制實例，然后對它進行序列化。

影響

序列化是令人擔(dān)憂的，因為它允許外部源獲取對您的對象的內(nèi)部狀態(tài)的控制。這一外部源可以將您的對象之一序列化成攻擊者隨后可以讀取的字節(jié)數(shù)組，這使得攻擊者可以完全審查您的對象的內(nèi)部狀態(tài)，包括您標記為 private 的任何字段。它也允許攻擊者訪問您引用的任何對象的內(nèi)部狀態(tài)。

建議

要防止類中的對象被序列化，請在類中定義清單 6 中的 writeObject() 方法：

清單 6. 防止對象序列化

private final void writeObject(ObjectOutputStream out)

throws java.io.NotSerializableException {

throw new java.io.NotSerializableException("This object cannot

be serialized");

}

通過將 writeObject() 方法聲明為 final，防止了攻擊者覆蓋該方法。

使類不可逆序列化

通過使用逆序列化，攻擊者可以用外部數(shù)據(jù)或字節(jié)流來實例化類。

影響

不管類是否可以序列化，都可以對它進行逆序列化。外部源可以創(chuàng)建逆序列化成類實例的字節(jié)序列。這種可能為您帶來了大量風(fēng)險，因為您不能控制逆序列化對象的狀態(tài)。請將逆序列化作為您的對象的另一種公共構(gòu)造器 — 一種您無法控制的構(gòu)造器。

建議

要防止對對象的逆序列化，應(yīng)該在您的類中定義清單 7 中的 readObject() 方法：

清單 7. 防止對象逆序列化

private final void readObject(ObjectInputStream in)

throws java.io.NotSerializableException {

throw new java.io.NotSerializableException("This object cannot

be deserialized");

}

通過將該方法聲明為 final，防止了攻擊者覆蓋該方法。

避免硬編碼敏感數(shù)據(jù)

您可能會嘗試將諸如加密密鑰之類的秘密存放在您的應(yīng)用程序或庫的代碼。對于你們開發(fā)人員來說，這樣做通常會把事情變得更簡單。

影響

任何運行您的代碼的人都可以完全訪問以這種方法存儲的秘密。沒有什么東西可以防止心懷叵測的程序員或虛擬機窺探您的代碼并了解其秘密。

建議

可以以一種只可被您解密的方式將秘密存儲在您代碼中。在這種情形下，秘密只在于您的代碼所使用的算法。這樣做沒有多大壞處，但不要洋洋得意，認為這樣做提供了牢固的保護。您可以遮掩您的源代碼或字節(jié)碼 — 也就是，以一種為了解密必須知道加密格式的方法對源代碼或字節(jié)碼進行加密 — 但攻擊者極有可能能夠推斷出加密格式，對遮掩的代碼進行逆向工程從而揭露其秘密。

這一問題的一種可能解決方案是：將敏感數(shù)據(jù)保存在屬性文件中，無論什么時候需要這些數(shù)據(jù)，都可以從該文件讀取。如果數(shù)據(jù)極其敏感，那么在訪問屬性文件時，您的應(yīng)用程序應(yīng)該使用一些加密／解密技術(shù)。

查找惡意代碼

從事某個項目的某個心懷叵測的開發(fā)人員可能故意引入易受攻擊的代碼，打算日后利用它。這樣的代碼在初始化時可能會啟動一個后臺進程，該進程可以為闖入者開后門。它也可以更改一些敏感數(shù)據(jù)。

這樣的惡意代碼有三類：

類中的 main 方法

定義過且未使用的方法

注釋中的死代碼

影響

入口點程序可能很危險而且有惡意。通常，Java 開發(fā)人員往往在其類中編寫 main() 方法，這有助于測試單個類的功能。當類從測試轉(zhuǎn)移到生產(chǎn)環(huán)境時，帶有 main() 方法的類就成為了對應(yīng)用程序的潛在威脅，因為闖入者將它們用作入口點。

請檢查代碼中是否有未使用的方法出現(xiàn)。這些方法在測試期間將會通過所有的安全檢查，因為在代碼中不調(diào)用它們 — 但它們可能含有硬編碼在它們內(nèi)部的敏感數(shù)據(jù)（雖然是測試數(shù)據(jù)）。引入一小段代碼的攻擊者隨后可能調(diào)用這樣的方法。

避免最終應(yīng)用程序中的死代碼（注釋內(nèi)的代碼）。如果闖入者去掉了對這樣的代碼的注釋，那么代碼可能會影響系統(tǒng)的功能性。

可以在清單 8 中看到所有三種類型的惡意代碼的示例：

清單 8. 潛在惡意的 Java 代碼

public void unusedMethod(){

// code written to harm the system

}

public void usedMethod(){

//unusedMethod(); //code in comment put with bad intentions,

//might affect the system if uncommented

// int x = 100;

// x=x+10; //Code in comment, might affect the

//functionality of the system if uncommented

}

建議

應(yīng)該將（除啟動應(yīng)用程序的 main() 方法之外的）main() 方法、未使用的方法以及死代碼從應(yīng)用程序代碼中除去。在軟件交付使用之前，主要開發(fā)人員應(yīng)該對敏感應(yīng)用程序進行一次全面的代碼評審。應(yīng)該使用“Stub”或“dummy”類代替 main() 方法以測試應(yīng)用程序的功能。

對付中等嚴重性暴露的技巧

請遵循下列建議以避免中等嚴重性靜態(tài)安全性暴露：

不要依賴初始化

不要通過名稱來比較類

不要使用內(nèi)部類

不要依賴初始化

您可以不運行構(gòu)造器而分配對象。這些對象使用起來不安全，因為它們不是通過構(gòu)造器初始化的。

影響

在初始化時驗證對象確保了數(shù)據(jù)的完整性。

例如，請想象為客戶創(chuàng)建新帳戶的 Account 對象。只有在 Account 期初余額大于 0 時，才可以開設(shè)新帳戶?？梢栽跇?gòu)造器里執(zhí)行這樣的驗證。有些人未執(zhí)行構(gòu)造器而創(chuàng)建 Account 對象，他可能創(chuàng)建了一個具有一些負值的新帳戶，這樣會使系統(tǒng)不一致，容易受到進一步的干預(yù)。

建議

在使用對象之前，請檢查對象的初始化過程。要做到這一點，每個類都應(yīng)該有一個在構(gòu)造器中設(shè)置的私有布爾標志，如清單 9 中的類所示。在每個非 static 方法中，代碼在任何進一步執(zhí)行之前都應(yīng)該檢查該標志的值。如果該標志的值為 true，那么控制應(yīng)該進一步繼續(xù)；否則，控制應(yīng)該拋出一個例外并停止執(zhí)行。那些從構(gòu)造器調(diào)用的方法將不會檢查初始化的變量，因為在調(diào)用方法時沒有設(shè)置標志。因為這些方法并不檢查標志，所以應(yīng)該將它們聲明為 private 以防止用戶直接訪問它們。

清單 9. 使用布爾標志以檢查初始化過程

public class MyClass{

private boolean initialized = false;

//Other variables

public MyClass (){

//variable initialization

method1();

initialized = true;

}

private void method1(){ //no need to check for initialization variable

//code

}

public void method2(){

try{

if(initialized==true){

//proceed with the business logic

}

else{

throw new Exception("Illegal State Of the object");

}

}catch(Exception e){

e.printStackTrace();

}

}

}

如果對象由逆序列化進行初始化，那么上面討論的驗證機制將難以奏效，因為在該過程中并不調(diào)用構(gòu)造器。在這種情況下，類應(yīng)該實現(xiàn) ObjectInputValidation 接口：

清單 10. 實現(xiàn) ObjectInputValidation

interface java.io.ObjectInputValidation {

public void validateObject() throws InvalidObjectException;

}

所有驗證都應(yīng)該在 validateObject() 方法中執(zhí)行。對象還必須調(diào)用 ObjectInputStream.RegisterValidation() 方法以為逆序列化對象之后的驗證進行注冊。 RegisterValidation() 的第一個參數(shù)是實現(xiàn) validateObject() 的對象，通常是對對象自身的引用。注：任何實現(xiàn) validateObject() 的對象都可能充當對象驗證器，但對象通常驗證它自己對其它對象的引用。RegisterValidation() 的第二個參數(shù)是一個確定回調(diào)順序的整數(shù)優(yōu)先級，優(yōu)先級數(shù)字大的比優(yōu)先級數(shù)字小的先回調(diào)。同一優(yōu)先級內(nèi)的回調(diào)順序則不確定。

當對象已逆序列化時，ObjectInputStream 按照從高到低的優(yōu)先級順序調(diào)用每個已注冊對象上的 validateObject()。

不要通過名稱來比較類

有時候，您可能需要比較兩個對象的類，以確定它們是否相同；或者，您可能想看看某個對象是否是某個特定類的實例。因為 JVM 可能包括多個具有相同名稱的類（具有相同名稱但卻在不同包內(nèi)的類），所以您不應(yīng)該根據(jù)名稱來比較類。

影響

如果根據(jù)名稱來比較類，您可能無意中將您不希望授予別人的權(quán)利授予了闖入者的類，因為闖入者可以定義與您的類同名的類。

例如，請假設(shè)您想確定某個對象是否是類 com.bar.Foo 的實例。清單 11 演示了完成這一任務(wù)的錯誤方法：

清單 11. 比較類的錯誤方法

if(obj.getClass().getName().equals("Foo")) // Wrong!

// objects class is named Foo

}else{

// object's class has some other name

}

建議

在那些非得根據(jù)名稱來比較類的情況下，您必須格外小心，必須確保使用了當前類的 ClassLoader 的當前名稱空間，如清單 12 中所示：

清單 12. 比較類的更好方法

if(obj.getClass() == this.getClassLoader().loadClass("com.bar.Foo")){

// object's class is equal to

//the class that this class calls "com.bar.Foo"

}else{

// object's class is not equal to the class that

// this class calls "com.bar.Foo"

}

然而，比較類的更好方法是直接比較類對象看它們是否相等。例如，如果您想確定兩個對象 a 和 b 是否屬同一個類，那么您就應(yīng)該使用清單 13 中的代碼：

清單 13. 直接比較對象來看它們是否相等

if(a.getClass() == b.getClass()){

// objects have the same class

}else{

// objects have different classes

}

盡可能少用直接名稱比較。

不要使用內(nèi)部類

Java 字節(jié)碼沒有內(nèi)部類的概念，因為編譯器將內(nèi)部類轉(zhuǎn)換成了普通類，而如果沒有將內(nèi)部類聲明為 private，則同一個包內(nèi)的任何代碼恰好能訪問該普通類。

影響

因為有這一特性，所以包內(nèi)的惡意代碼可以訪問這些內(nèi)部類。如果內(nèi)部類能夠訪問括起外部類的字段，那么情況會變得更糟?？赡芤呀?jīng)將這些字段聲明為 private，這樣內(nèi)部類就被轉(zhuǎn)換成了獨立類，但當內(nèi)部類訪問外部類的字段時，編譯器就將這些字段從專用（private）的變?yōu)樵诎╬ackage）的作用域內(nèi)有效的。內(nèi)部類暴露了已經(jīng)夠糟糕的了，但更糟糕的是編譯器使您將某些字段成為 private 的舉動成為徒勞。

建議 如果能夠不使用內(nèi)部類就不要使用內(nèi)部類。

對付低嚴重性暴露的技巧

請遵循下列建議以避免低嚴重性靜態(tài)安全性暴露：

避免返回可變對象

檢查本機方法

避免返回可變對象

Java 方法返回對象引用的副本。如果實際對象是可改變的，那么使用這樣一個引用調(diào)用程序可能會改變它的內(nèi)容，通常這是我們所不希望見到的。

影響

請考慮這個示例：某個方法返回一個對敏感對象的內(nèi)部數(shù)組的引用，假定該方法的調(diào)用程序不改變這些對象。即使數(shù)組對象本身是不可改變的，也可以在數(shù)組對象以外操作數(shù)組的內(nèi)容，這種操作將反映在返回該數(shù)組的對象中。如果該方法返回可改變的對象，那么事情會變得更糟；外部實體可以改變在那個類中聲明的 public 變量，這種改變將反映在實際對象中。

清單 14 演示了脆弱性。getExposedObj() 方法返回了 Exposed 對象的引用副本，該對象是可變的：

清單 14. 返回可變對象的引用副本

class Exposed{

private int id;

private String name;

public Exposed(){

}

public Exposed(int id, String name){

this.id = id;

this.name = name;

}

public int getId(){

return id;

}

public String getName(){

return name;

}

public void setId(int id){

this.id=id;

}

public void setName(String name){

this.name = name;

}

public void display(){

System.out.println("Id = "+ id + " Name = "+ name);

}

}

public class Exp12{

private Exposed exposedObj = new Exposed(1,"Harry Porter");

public Exposed getExposedObj(){

return exposedObj; //returns a reference to the object.

}

public static void main(String[] args){

Exp12 exp12 = new Exp12();

exp12.getExposedObj().display();

Exposed exposed = exp12.getExposedObj();

exposed.setId(10);

exposed.setName("Hacker");

exp12.getExposedObj().display();

}

}

建議

如果方法返回可改變的對象，但又不希望調(diào)用程序改變該對象，請修改該方法使之不返回實際對象而是返回它的副本或克隆。要改正清單 14 中的代碼，請讓它返回 Exposed 對象的副本,如清單 15 中所示：

清單 15. 返回可變對象的副本

public Exposed getExposedObj(){

return new Exposed(exposedObj.getId(),exposedObj.getName());

}

或者，您的代碼也可以返回 Exposed 對象的克隆。

檢查本機方法

本機方法是一種 Java 方法，其實現(xiàn)是用另一種編程語言編寫的，如 C 或 C++。有些開發(fā)人員實現(xiàn)本機方法，這是因為 Java 語言即使使用即時（just-in-time）編譯器也比許多編譯過的語言要慢。其它人需要使用本機代碼是為了在 JVM 以外實現(xiàn)特定于平臺的功能。

影響

使用本機代碼時，請小心，因為對這些代碼進行驗證是不可能的，而且本機代碼可能潛在地允許 applet 繞過通常的安全性管理器（Security Manager）和 Java 對設(shè)備訪問的控制。

建議

如果非得使用本機方法，那么請檢查這些方法以確定：

它們返回什么

它們獲取什么作為參數(shù)

它們是否繞過安全性檢查

它們是否是 public、private 等等

它們是否含有繞過包邊界從而繞過包保護的方法調(diào)用

結(jié)束語

編寫安全 Java 代碼是十分困難的，但本文描述了一些可行的實踐來幫您編寫安全 Java 代碼。這些建議并不能解決您的所有安全性問題，但它們將減少暴露數(shù)目。最佳軟件安全性實踐可以幫助確保軟件正常運行。安全至關(guān)重要和高可靠系統(tǒng)設(shè)計者總是花費大量精力來分析和跟蹤軟件行為。只有通過將安全性作為至關(guān)緊要的系統(tǒng)特性來對待 — 并且從一開始就將它構(gòu)建到應(yīng)用程序中，我們才可以避免亡羊補牢似的、修修補補的安全性方法。

參考資料

請通過單擊文章頂部或底部的討論來參加本文的論壇。

了解關(guān)于 Java 安全性 API 的更多知識。

developerWorks 安全專題上通常含有有關(guān)計算機安全性的優(yōu)秀資源。

Larry Koved、 Anthony J. Nadalin、Don Neal 和 Tim Lawson 合作編寫的 “The evolution of Java security”（developerWorks，1998 年）對 Java 語言的安全性模型早期開發(fā)進行了深入探討。

Sing Li 在他的 Java 安全性系列文章（由兩部分組成的）（developerWorks， 2001 年 2 月）中向開發(fā)人員顯示：盡管社區(qū)可能不得不重新考慮 Java 2 中的安全性設(shè)計，還是出現(xiàn)了只對開發(fā)人員有幫助，可以滿足他們的需求的一致的進展：

第一部分

第二部分

John Viega、Tom Mutdosch、 Gary McGraw 和 Ed Felten 合著的 “Statically scanning Java code for security vulnerabilities” （IEEE Software，2000 年 9 月）介紹了一種 Java 工具，可以使用該工具來檢查您的 Java 代碼中的安全性漏洞。

G. McGraw 和 E. Felten 合作編寫的 Securing Java: Getting Down to Business with Mobile Code（John Wiley 和 Sons，1998 年）深入涵蓋了 Java 安全性。（文檔是 PDF 格式的。）

定期檢查 IBM 研究 Java 安全頁面以便 IBM 在安全性領(lǐng)域的創(chuàng)新有重要發(fā)展時能夠跟蹤這一創(chuàng)新。

如果您的 Java 代碼運行在 S/390 系統(tǒng)上，那么您將需要查閱 S/390 Java 安全頁面以獲取額外的信息。

關(guān)于作者

Bijaya Nanda Sahu 是就職于印度 IBM Global Services 的軟件工程師。他從事過各種因特網(wǎng)技術(shù)和框架（J2EE、WSBCC、JADE）、 WebSphere 相關(guān)技術(shù)、UML 和 OOAD 方面的工作。目前，他從事因特網(wǎng)銀行安全性問題方面的工作，重點在 WebSphere Application Server 和 Portal Server 上。可以通過 bijaya.sahu@in.ibm.com 和他聯(lián)系

網(wǎng)絡(luò)攻擊里面ddos攻擊和cc攻擊區(qū)別是什么？

CC攻擊是DDoS攻擊的其中一種，DDoS攻擊方式還有：ICMP Flood、UDP Flood、NTP Flood...

CC攻擊是目前應(yīng)用層攻擊的主要手段之一，借助代理服務(wù)器生成指向目標系統(tǒng)的合法請求，實現(xiàn)偽裝和DDoS。我們都有這樣的體驗，訪問一個靜態(tài)頁面，即使人多也不需要太長時間，但如果在高峰期訪問論壇、貼吧等，那就很慢了，因為服務(wù)器系統(tǒng)需要到數(shù)據(jù)庫中判斷訪問者否有讀帖、發(fā)言等權(quán)限。訪問的人越多，論壇的頁面越多，數(shù)據(jù)庫壓力就越大，被訪問的頻率也越高，占用的系統(tǒng)資源也就相當可觀。

CC攻擊就充分利用了這個特點，模擬多個正常用戶不停地訪問如論壇這些需要大量數(shù)據(jù)操作的頁面，造成服務(wù)器資源的浪費，CPU長時間處于100%，永遠都有處理不完的請求，網(wǎng)絡(luò)擁塞，正常訪問被中止。這種攻擊技術(shù)性含量高，見不到真實源IP，見不到特別大的異常流量，但服務(wù)器就是無法進行正常連接。

之所以選擇代理服務(wù)器是因為代理可以有效地隱藏自己的身份，也可以繞開防火墻，因為基本上所有的防火墻都會檢測并發(fā)的TCP/IP連接數(shù)目，超過一定數(shù)目一定頻率就會被認為是Connection-Flood。當然也可以使用肉雞來發(fā)動CC攻擊，攻擊者使用CC攻擊軟件控制大量肉雞發(fā)動攻擊，肉雞可以模擬正常用戶訪問網(wǎng)站的請求偽造成合法數(shù)據(jù)包，相比前者來說更難防御。

CC攻擊是針對Web服務(wù)在第七層協(xié)議發(fā)起的攻擊，在越上層協(xié)議上發(fā)動DDoS攻擊越難以防御，上層協(xié)議與業(yè)務(wù)關(guān)聯(lián)愈加緊密，防御系統(tǒng)面臨的情況也會更復(fù)雜。比如CC攻擊中最重要的方式之一HTTP Flood，不僅會直接導(dǎo)致被攻擊的Web前端響應(yīng)緩慢，對承載的業(yè)務(wù)造成致命的影響，還可能會引起連鎖反應(yīng)，間接攻擊到后端的Java等業(yè)務(wù)層邏輯以及更后端的數(shù)據(jù)庫服務(wù)。

由于CC攻擊成本低、威力大，知道創(chuàng)宇安全專家組發(fā)現(xiàn)80%的DDoS攻擊都是CC攻擊。帶寬資源嚴重被消耗，網(wǎng)站癱瘓；CPU、內(nèi)存利用率飆升，主機癱瘓；瞬間快速打擊，無法快速響應(yīng)。相關(guān)鏈接

Java加密，解密中的bc，cc是啥意思

不知道你說的是不是這個：

AES五種加密模式（CBC、ECB、CTR、OCF、CFB）

分組密碼有五種工作體制：

電碼本模式（Electronic?Codebook?Book?(ECB)）；

密碼分組鏈接模式（Cipher?Block?Chaining?(CBC)）；

計算器模式（Counter?(CTR)）；

密碼反饋模式（Cipher?FeedBack?(CFB)）；

輸出反饋模式（Output?FeedBack?(OFB)）。

cc攻擊是什么意思？怎么防護

HTTP Flood 俗稱CC攻擊（Challenge Collapsar）是DDOS（分布式拒絕服務(wù)）的一種，前身名為Fatboy攻擊，也是一種常見的網(wǎng)站攻擊方法。是針對 Web 服務(wù)在第七層協(xié)議發(fā)起的攻擊。攻擊者相較其他三層和四層，并不需要控制大量的肉雞，取而代之的是通過端口掃描程序在互聯(lián)網(wǎng)上尋找匿名的 HTTP 代理或者 SOCKS 代理，攻擊者通過匿名代理對攻擊目標發(fā)起HTTP 請求。匿名代理服務(wù)器在互聯(lián)網(wǎng)上廣泛存在。因此攻擊容易發(fā)起而且可以保持長期高強度的持續(xù)攻擊，同樣可以隱藏攻擊者來源避免被追查。

HTTP/CC 攻擊的特點：

HTTP/CC 攻擊的 ip 都是真實的，分散的

HTTP/CC 攻擊的數(shù)據(jù)包都是正常的數(shù)據(jù)包

HTTP/CC 攻擊的請求都是有效請求，且無法拒絕

HTTP/CC 攻擊的是網(wǎng)頁，服務(wù)器可以連接，ping 也沒問題，但是網(wǎng)頁就是訪問不了

如果 WEB環(huán)境 一開，服務(wù)器很快就死，容易丟包。

那如何造成更大的殺傷呢。Web 服務(wù)與 DNS 服務(wù)類似，也存在緩存機制。如果攻擊者的大量請求命中了服務(wù)器緩存，那么這種攻擊的主要作用僅體現(xiàn)在消耗網(wǎng)絡(luò)帶寬資源上，對于計算和 IO 資源的消耗是非常有限的。因此，高效的 HTTP/CC 攻擊 應(yīng)不斷發(fā)出針對不同資源和頁面的 HTTP 請求，并盡可能請求無法被緩存的資源（ 如關(guān)鍵詞搜索結(jié)果、用戶相關(guān)資料等 ），這樣才能更好的加重服務(wù)器的負擔(dān)，達到理想的攻擊效果。當然 HTTP/CC 攻擊 也會引起嚴重的連鎖反應(yīng)，不僅僅是直接導(dǎo)致被攻擊的 Web 前端響應(yīng)緩慢，還間接攻擊到后端的 Java 等業(yè)務(wù)層邏輯以及更后端的數(shù)據(jù)庫服務(wù)，增大它們的壓力，HTTP/CC 攻擊 產(chǎn)生的海量日志數(shù)據(jù)甚至?xí)θ罩敬鎯Ψ?wù)器都帶來影響。

如果 Web 服務(wù)器支持 HTTPS，那么進行 HTTPS 洪水攻擊是更為有效的一種攻擊方式。原因有二：

其一，在進行 HTTPS 通信時，Web 服務(wù)器需要消耗更多的資源用來認證和加解密。

其二，目前一部分防護設(shè)備無法對 HTTPS 通信數(shù)據(jù)流進行處理，會導(dǎo)致攻擊流量繞過防護設(shè)備，直接對 Web 服務(wù)器造成攻擊。

簡易CC攻擊防御方法

1. 把網(wǎng)站做成靜態(tài)頁面：

大量事實證明，把網(wǎng)站盡可能做成靜態(tài)頁面，不僅能大大提高抗攻擊能力，而且還給駭客入侵帶來不少麻煩，至少到現(xiàn)在為止關(guān)于HTML的溢出還沒出現(xiàn)，看看吧！新浪、搜狐、網(wǎng)易等門戶網(wǎng)站主要都是靜態(tài)頁面，若你非需要動態(tài)腳本調(diào)用，那就把它弄到另外一臺單獨主機去，免的遭受攻擊時連累主服務(wù)器。

2. 在存在多站的服務(wù)器上，嚴格限制每一個站允許的IP連接數(shù)和CPU使用時間

這是一個很有效的方法。CC的防御要從代碼做起，其實一個好的頁面代碼都應(yīng)該注意這些東西，還有SQL注入，不光是一個入侵工具，更是一個DDOS缺口，大家都應(yīng)該在代碼中注意。舉個例子吧，某服務(wù)器，開動了5000線的CC攻擊，沒有一點反應(yīng)，因為它所有的訪問數(shù)據(jù)庫請求都必須一個隨機參數(shù)在Session里面，全是靜態(tài)頁面，沒有效果。突然發(fā)現(xiàn)它有一個請求會和外面的服務(wù)器聯(lián)系獲得，需要較長的時間，而且沒有什么認證，開800線攻擊，服務(wù)器馬上滿負荷了。代碼層的防御需要從點點滴滴做起，一個腳本代碼的錯誤，可能帶來的是整個站的影響，甚至是整個服務(wù)器的影響!

5. 服務(wù)器前端加CDN中轉(zhuǎn)

可以購買高CDN百度云加速，用于隱藏服務(wù)器真實IP，域名解析使用CDN的IP，所有解析的子域名都使用CDN的IP地址。此外，服務(wù)器上部署的其他域名也不能使用真實IP解析，全部都使用CDN來解析，百度云加速提供四到七層的DDoS攻擊防護，包括CC、SYN flood、UDP flood等所有DDoS攻擊方式， 通過分布式高性能防火墻+精準流量清洗+CC防御+WEB攻擊攔截，組合過濾精確識別，有效防御各種類型攻擊。相關(guān)鏈接

網(wǎng)頁名稱：javacc攻擊代碼 java dos攻擊
網(wǎng)站鏈接：http://muchs.cn/article6/dohseog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、網(wǎng)站設(shè)計公司、建站公司、自適應(yīng)網(wǎng)站、Google、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)