常用網站攻擊手段及防禦方法
常見的攻擊手段--XSS
XSS攻擊的全稱是跨站指令碼攻擊(Cross Site Scripting)，為不跟層疊樣式表(Cascading Style Sheets,CSS)的縮寫混淆，故將跨站指令碼攻擊縮寫為XSS,是WEB應用程式中最常見到的攻擊手段之一。跨站指令碼攻擊指的是攻擊者在網頁中嵌入惡意指令碼程式，當用戶開啟該網頁時，指令碼程式便開始在客戶端的瀏覽器上執行，以盜取客戶端cookie、盜取使用者名稱密碼、下載執行病毒木馬程式甚至是獲取客戶端admin許可權等等。
如：<input type="text" name="nick" value=""/><script>alert("haha")</script><!-" />當頁面訪問時候就會alert提示。
還有一種場景，使用者在表單上輸入一段資料後，提交給服務端進行持久化，其他頁面上需要從服務端將資料取出來展示。還是使用之前那個表單nick，使用者輸入暱稱之後，服務端會將nick儲存，並在新的頁面展現給使用者，當普通使用者正常輸入zhangsan，頁面會顯示使用者的
nick為zhangsan：
<body>
zhangsan
</body>
但是，如果使用者輸入的不是一段正常的nick字串，而是<script>alert("haha")</script>，服務端會將這段指令碼儲存起來，當有使用者檢視該頁面時，頁面會出現如下程式碼：
<body>
<script>alert("haha")</script>
</body>
XSS該如何防禦
XSS之所以會發生，是因為使用者輸入的資料變成了程式碼。因此，我們需要對使用者
輸入的資料進行HTML轉義處理，將其中的“尖括號”、“單引號”、“引號” 之類的特殊字元進行轉義編碼。如今很多開源的開發框架本身預設就提供HTML程式碼轉義的功能，如流行的jstl、 Struts等等不需要開發人員再進行過多的開發。使用jstl標籤進行HTML轉義，將變數輸出，程式碼
一：頁面轉義：
如下：<c:out value="${nick}" escapeXml="true"></c:out> 只需要將escapeXml設定為true，jstl就會將變數中的HTML程式碼進行轉義輸出。
也可以通過Filter過濾請求引數，通過對特殊字元轉義。
二：SprinMVC 的XSS 防範：
web.xml加上：
<context-param>
<param-name>defaultHtmlEscape</param-name>
<param-value>true</param-value>
</context-param>
Forms頁面加上：
<spring:htmlEscape defaultHtmlEscape="true" />
三：通過程式碼過濾請求引數
如下過濾程式碼：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 |
/**
* 過濾xss攻擊
* @author tony
*
*/
public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper {
/**
* The request parameters for this request. This is initialized from the
* wrapped request, but updates are allowed.
*/
protected Map<String, String[]> parameters = null;
public XssHttpServletRequestWrapper(HttpServletRequest request) {
super(request);
}
public String[] getParameterValues(String parameter) {
return parseParameters(parameter);
}
public String getParameter(String parameter) {
String[] value =parseParameters(parameter);
if (value == null) {
return null;
}
return value[0];
}
public String getHeader(String name) {
String value = super.getHeader(name);
if (value == null)
return null;
//return cleanXSS(value);
return value;
}
private String[] parseParameters(String name) {
if (parameters == null) {
parameters = new HashMap<String, String[]>();
}
String[] values = parameters.get(name);
if(values != null){
return values;
}else{
values = super.getParameterValues(name);
if(values != null){
int count = values.length;
String[] encodedValues = new String[count];
for (int i = 0; i < count; i++) {
encodedValues[i] = cleanXSS(values[i]);//轉換
}
parameters.put(name, encodedValues);//放置轉換好的引數
}
}
return values;
}
/**
* 過濾Html javascript 和sql
* @param src
* @return
*/
private String cleanXSS(String value) {
if(AppUtils.isBlank(value)){
return value;
}
//You'll need to remove the spaces from the html entities below
value = value.replaceAll("<", "& lt;").replaceAll(">", "& gt;");
value = value.replaceAll("\\(", "& #40;").replaceAll("\\)", "& #41;");
value = value.replaceAll("'", "& #39;");
value = value.replaceAll("eval\\((.*)\\)", "");
value = value.replaceAll("[\\\"\\\'][\\s]*javascript:(.*)[\\\"\\\']", "\"\"");
return value;
}
}
|
常見的攻擊手段--CSRF
CSRF攻擊的全稱是跨站請求偽造(cross site request forgery)，是一種對網站的惡意利用，儘管聽起來跟XSS跨站指令碼攻擊有點相似，但
事實上CSRF與XSS差別很大， XSS利用的是站點內的信任使用者，而CSRF則是通過偽裝來自受信任使用者的請求來利用受信任的網站。你可以這麼理解
CSRF攻擊：攻擊者盜用了你的身份，以你的名義向第三方網站傳送惡意請求。 CRSF能做的事情包括利用你的身份發郵件、發簡訊、進行交易轉賬等等，甚至盜取你的賬號。
舉個例子來說吧(受害者的網址是a.cn，攻擊者的網址是b.cn)攻擊者想要在某個網站(網站是某個開源CMS)新增上另一個管理員，但是這個網站並沒有XSS漏洞。怎麼辦呢？這時攻擊者發現了這個開源CMS後臺新增管理員時並沒有加入驗證碼或則token，只需要輸入要新增的管理員賬號和密碼點選確定就可以新增管理員賬戶了。這時和我一樣聰明的攻擊者在自己的伺服器上建立了一個html檔案(假設地址是b.cn/index.html)。然後就給網站管理員發郵件等等，誘使管理員開啟b.cn/index.html。當管理員開啟後（這時管理員正在網站後臺，或則管理員的session並沒有失效的話），就可以神不知鬼不覺的在網站後臺添加了一個管理員賬戶。
又或者
假設某銀行網站A，他以GET請求來發起轉賬操作，轉賬的地址為www.xxx.com/transfer.do?accountNum=10001&money=10000， accountNum引數表示轉賬的目的賬戶， money引數表示轉賬金額。而某大型論壇B上，一個惡意使用者上傳了一張圖片，而圖片的位址列中填的並不是圖片的地
址，而是前面所說的轉賬地址：<img src="http://www.xxx.com/transfer.do?accountNum=10001&money=10000">當你登陸網站A後，沒有及時登出，這個時候你訪問了論壇B，不幸的事情發生了，你會發現你的賬戶裡面少了10000塊……為什麼會這樣呢，在你登陸銀行A的時候，你的瀏覽器端會生成銀行A的cookie，而當你訪問論壇B的時候，頁面上的<img>標籤需要瀏覽器發起一個新的HTTP請求，以獲得圖片資源，當瀏覽器發起請求的時候，請求的卻是銀行A的轉賬地址www.xxx.com/transfer.do?accountNum=10001&money=10000，並且會帶上銀行A的cookie資訊，結果銀行的伺服器收到這個請求後，會認為是你發起的一次轉賬操作，因此你的賬戶裡邊便少了10000塊。
常見的攻擊手段—CSRF的防禦：
1.cookie設定為HttpOnly
CSRF攻擊很大程度上是利用了瀏覽器的cookie，為了防止站內的XSS漏洞盜取cookie，需要在cookie中設定"HttpOnly"屬性，這樣通過程式(如JavascriptS指令碼、 Applet等)就無法讀
取到cookie資訊，避免了攻擊者偽造cookie的情況出現。
2.增加token
CSRF攻擊之所以能夠成功，是因為攻擊者可以偽造使用者的請求，該請求中所有的使用者驗證資訊都存在於cookie中，因此攻擊者可以在不知道使用者驗證資訊的情況下直接利用使用者的cookie來通過安全驗證。由此可知，抵禦CSRF攻擊的關鍵在於：在請求中放入攻擊者所不
能偽造的資訊，並且該資訊不存在於cookie之中。鑑於此，系統開發人員可以在HTTP請求中以引數的形式加入一個隨機產生的token，並在服務端進行token校驗，如果請求中沒有token或者token內容不正確，則認為是CSRF攻擊而拒絕該請求。
如：
開啟Form頁面的時候在服務端生成Token並儲存到Session中，例如：
String token = UUID.randomUUID().toString();
session.setAttribute("CSRFToken", token);
request.addAttribute("csrf", token);
然後在Form中新增Hidden field:
<input type="hidden" name="CSRFToken" value="${csrf}" />
然後在後臺提交的時候驗證token是否正確
String token= (String) session.getAttribute("CSRFToken");
3.通過Referer識別
根據HTTP協議，在HTTP頭中有一個欄位叫Referer，它記錄了該HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求都來自於同一個網站。比如某銀行的轉賬是通過使用者訪問http://www.xxx.com/transfer.do頁面完成，使用者必須先登入www.xxx.com，然後通過點選頁面上的提交按鈕來觸發轉賬事件。當用戶提交請求時，該轉賬請求的Referer值就會是提交按鈕所在頁面的URL（本例為www.xxx.com/transfer.do）。如果攻擊者要對銀行網站實施CSRF攻擊，他只能在其他的網站構造請求，當用戶通過其他網站傳送請求到銀行時，該請求的Referer的值是其他網站的地址，而不是銀行轉賬頁面的地址。因此，要防禦CSRF攻擊，銀行網站只需要對於每一個轉賬請求驗證其Referer值，如果是以www.xxx.com域名開頭的地址，則說明該請求是來自銀行網站自己的請求，是合法的。如果Referer是其他網站的話，就有可能是CSRF攻擊，則拒絕該請求。
如：request.getHeader("referer"); 獲取來源資訊。
常見的攻擊手段—SQL注入攻擊：
所謂SQL注入，就是通過把SQL命令偽裝成正常的HTTP請求引數，傳遞到服務端，欺騙伺服器最終執行惡意的SQL命令，達到入侵目的。攻擊者可以利用SQL注入漏洞，查詢非授權資訊，修改資料庫伺服器的資料，改變表結構，甚至是獲取伺服器root許可權。總而言之， SQL注入漏洞的危害極大，攻擊者採用的SQL指令，決定攻擊的威力。當前涉及到大批量資料洩露的攻擊事件，大部分都是通過利用SQL注入來實施的。
常見的攻擊手段—SQL注入攻擊原理：
假設有個網站的登入頁面，如下所示：
假設使用者輸入nick為zhangsan，密碼為password1，則驗證通過，顯示使用者登入：
否則，顯示使用者沒有登入：
常見的攻擊手段—SQL注入攻擊原理
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Connection conn = getConnection();
String sql = "select * from hhuser where nick = '" + nickname +
"'" + " and passwords = '" + password + "'";
Statement st = (Statement) conn.createStatement();
ResultSet rs = st.executeQuery(sql);
List<UserInfo> userInfoList = new ArrayList<UserInfo>();
while (rs.next()) {
UserInfo userinfo = new UserInfo();
userinfo.setUserid(rs.getLong("userid"));
userinfo.setPasswords(rs.getString("passwords"));
userinfo.setNick(rs.getString("nick"));
userinfo.setAge(rs.getInt("age"));
userinfo.setAddress(rs.getString("address"));
userInfoList.add(userinfo);
}
|
當用戶輸入nick為zhangsan，密碼為' or '1'='1的時候，意想不到的事情出現了，頁面
顯示為login狀態：
以上便是一次簡單的、典型的SQL注入攻擊。當然， SQL注入的危害不僅如此，假設使用者輸入使用者名稱zhangsan，在密碼框輸入' ;drop tableaaa;--， 會發生什麼呢？
常見的攻擊手段—SQL注入攻擊防禦：
1. 使用預編譯語句
預編譯語句PreparedStatement是java.sql中的一個介面，繼承自Statement介面。通過Statement物件執行SQL語句時，需要將SQL語句傳送給DBMS，由DBMS先進行編譯後再執行。而預編譯語句和Statement不同，在建立PreparedStatement物件時就指定了SQL語句，該語句立即發
送給DBMS進行編譯，當該編譯語句需要被執行時， DBMS直接執行編譯後的SQL語句，而不需要像其他SQL語句那樣首先將其編譯。
前面介紹過，引發SQL注入的根本原因是惡意使用者將SQL指令偽裝成引數傳遞到後端資料庫執行，作為一種更為安全的動態字串的構建方法，預編譯語句使用引數佔位符來替代需要動態傳入的引數，這樣攻擊者無法改變SQL語句的結構， SQL語句的語義不會發生改變，即便使用者傳入類似於
前面' or '1'='1這樣的字串，資料庫也會將其作為普通的字串來處理。
2. 使用ORM框架
由上文可見，防止SQL注入的關鍵在於對一些關鍵字元進行轉義，而常見的一些ORM框架，如ibatis、 hibernate等，都支援對相應的關鍵字或者特殊符號進行轉義，可以通過簡單的配置，很好的預防SQL注入漏洞，降低了普通的開發人員進行安全程式設計的門檻。
Ibatis的insert語句配置：
<insert id="insert" parameterClass="userDO">
insert into
users(gmt_create,gmt_modified,userid,user_nick,address,age,sex)
values(now(),now(),#userId#,#userNick#,#address#,#age#,#sex#)
</insert>
通過#符號配置的變數， ibatis能夠對輸入變數的一些關鍵字進行轉義，防止SQL注入攻擊。
3.避免密碼明文存放
對儲存的密碼進行單向Hash，如使用MD5對密碼進行摘要，而非直接儲存明文密碼，這樣的好處就是萬一使用者資訊洩露，即圈內所說的被“拖庫”，黑客無法直接獲取使用者密碼，而只能得到一串跟密碼相差十萬八千里的Hash碼。12306網站就出現“拖庫”事件
4.處理好相應的異常
後臺的系統異常，很可能包含了一些如伺服器版本、資料庫版本、程式語言等等的資訊，甚至是資料庫連線的地址及使用者名稱密碼，攻擊者可以按圖索驥，找到對應版本的伺服器漏洞或者資料庫漏洞進行攻擊，因此，必須要處理好後臺的系統異常，重定向到相應的錯誤處理頁面，而不是任由其直接輸出到頁面上。
常見的攻擊手段—檔案上傳漏洞：
在上網的過程中，我們經常會將一些如圖片、壓縮包之類的檔案上傳到遠端伺服器進行儲存，檔案上傳攻擊指的是惡意攻擊者利用一些站點沒有對檔案的型別做很好的校驗這樣的漏洞，上傳了可執行的檔案或者指令碼，並且通過指令碼獲得伺服器上相應的權利，或者是通過誘導外部使用者訪問或者下載上傳的病毒或者木馬檔案，達到攻擊目的。為了防範使用者上傳惡意的可執行檔案和指令碼，以及將檔案上傳伺服器當做免費的檔案儲存伺服器使用，需要對上傳的檔案型別進行白名單(非黑名單，這點非常重要)校驗，並且限制上傳檔案的大小，上傳的檔案，需要進行重新命名，使攻擊者無法猜測到上傳檔案的訪問路徑。對於上傳的檔案來說，不能簡單的通過後綴名稱來判斷檔案的型別，因為惡意攻擊可以將可執行檔案的字尾名稱改成圖片或者其他的字尾型別，誘導使用者執行。因此，判斷檔案型別需要使用更安全的方式。很多型別的檔案，起始的幾個位元組內容是固定的，因此，根據這幾個位元組的內容，就可以確定檔案型別，這幾個位元組也被稱為魔數(magic number)。
如：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 |
public enum FileType {
/**
* JEPG.
*/
JPEG("FFD8FF"),
/**
* PNG.
*/
PNG("89504E47"),
/**
* GIF.
*/
GIF("47494638"),
/**
* TIFF.
*/
TIFF("49492A00"),
/**
* Windows Bitmap.
*/
BMP("424D"),
/**
* CAD.
*/
DWG("41433130"),
/**
* Adobe Photoshop.
*/
PSD("38425053"),
/**
* XML.
*/
XML("3C3F786D6C"),
/**
* HTML.
*/
HTML("68746D6C3E"),
/**
* Adobe Acrobat.
*/
PDF("255044462D312E"),
/**
* ZIP Archive.
*/
ZIP("504B0304"),
/**
* RAR Archive.
*/
RAR("52617221"),
/**
* Wave.
*/
WAV("57415645"),
/**
* AVI.
*/
AVI("41564920");
private String value = "";
/**
* Constructor.
*
* @param type
*/
private FileType(String value) {
this.value = value;
}
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
}
public final class FileTypeValidate{
/**
* 二進位制轉化為16進位制
*/
private static String bytes2hex(byte[] bytes) {
StringBuilder hex = new StringBuilder();
for (int i = 0; i < bytes.length; i++) {
String temp = Integer.toHexString(bytes[i] & 0xFF);
if (temp.length() == 1) {
hex.append("0");
}
hex.append(temp.toLowerCase());
}
return hex.toString();
}
/**
* 讀取檔案頭
*/
private static String getFileHeader(String filePath) throws IOException {
byte[] b = new byte[28];//這裡需要注意的是,每個檔案的magic word的長度都不相同,因此需要使用startwith
InputStream inputStream = null;
inputStream = new FileInputStream(filePath);
inputStream.read(b, 0, 28);
inputStream.close();
return bytes2hex(b);
}
/**
* 判斷檔案型別
*/
public static FileType getType(String filePath) throws IOException {
String fileHead = getFileHeader(filePath);
if (fileHead == null || fileHead.length() == 0) {
return null;
}
fileHead = fileHead.toUpperCase();
FileType[] fileTypes = FileType.values();
for (FileType type : fileTypes) {
if (fileHead.startsWith(type.getValue())) {
return type;
}
}
return null;
}
public static void main(String[] args) throws Exception{
System.out.println(FileTypeJudge.getType("D:\\Download\\doc.rar"));
}
}
|
參考地址：http://blog.csdn.net/ivan0609/article/details/44535365
常見的攻擊手段—DDoS：
DDoS(Distributed Denial of Service)，即分散式拒絕服務攻擊，是目前最為強大、最難以防禦的攻擊方式之一。要理解DDos，得先從DoS說起。最基本的DoS攻擊就是利用合理的客戶端請求來佔用過多的伺服器資源，從而使合法使用者無法得到伺服器的響應。 DDoS攻擊手段是在傳統的DoS攻擊基礎之上產生的一類攻擊方式，傳統的DoS攻擊一般是採用一對一方式的，當攻擊目標CPU速度、記憶體或者網路頻寬等等各項效能指標不高的情況下，它的效果是明顯的，但隨著計算機與網路技術的發展，計算機的處理能力顯著增加，記憶體不斷增大，同時也出現了千兆級別的網路，這使得DoS攻擊逐漸失去效果。這時候分散式拒絕服務攻擊手段（ DDoS）便應運而生了。你理解了DoS攻擊以後，DDoS的原理就非常簡單了，它指的是攻擊者藉助公共網路，將數量龐大的計算機裝置聯合起來作為攻擊平臺，對一個或多個目標發動攻擊，從而達到癱瘓目標主機的目的。通常，在攻擊開始前，攻擊者會提前控制大量的使用者計算機，稱之為“肉雞”，並通過指令使大量的肉雞在同一時刻對某個主機進行訪問，從而達到癱瘓目標主機的目的。
DDoS的攻擊有很多種型別，如依賴蠻力的ICMP Flood、 UDP Flood等等，隨著硬體效能的提升，需要的機器規模越來越大，組織大規模的攻擊越來越困難，現在已經不常見，還有就是依賴協議特徵以及具體的軟體漏洞進行的攻擊，如Slowloris攻擊， Hash碰撞攻擊等等，這類攻擊主要利用協議以及軟體漏洞發起攻擊，需要在特定環境下才會出現，更多的攻擊者採用的是前面兩種的混合方式，即利用了協議、系統的缺陷，又具備了海量的流量，如SYN Flood、 DNS Query Flood等等
參考資料：http://blog.csdn.net/bill_lee_sh_cn/article/details/6065704
常見的攻擊手段—DNS Query Flood:
DNS Query Flood實際上是UDP Flood攻擊的一種變形，由於DNS服務在網際網路中不可替代的作用，一旦DNS伺服器癱瘓，影響甚大。DNS Query Flood攻擊採用的方法是向被攻擊的伺服器傳送海量的域名解析請求，通常，請求解析的域名是隨機生成，大部分根本就不存在，並且通過偽造埠和客戶端IP，防止查詢請求被ACL過濾。被攻擊的DNS 伺服器在接收到域名解析請求後，首先會在伺服器上查詢是否有對應的快取，由於域名是隨機生成的，幾乎不可能有相應的快取資訊，當沒有快取，並且該域名無法直接由該DNS伺服器進行解析的時候， DNS伺服器會向其上層DNS伺服器遞迴查詢域名資訊，直到全球網際網路的13臺根DNS伺服器。大量不存在的域名解析請求，給伺服器帶來了很大的負載，當解析請求超過一定量的時候，就會造成DNS伺服器解析域名超時，這樣攻擊者便達成了攻擊目的。
常見的攻擊手段—CC攻擊:
CC(Challenge Collapsar)攻擊屬於DDos的一種，是基於應用層HTTP協議發起的DDos攻擊，也被稱為HTTP Flood。CC攻擊的原理是這樣的，攻擊者通過控制的大量“肉雞”或者利用從網際網路上搜尋的大量匿名的HTTP代理，模擬正常使用者給網站發起請求直到該網站拒絕服務為止。大部分網站會通過CDN以及分散式快取來加快服務端響應，提升網站的吞吐量，而這些精心構造的HTTP請求往往有意避開這些快取，需要進行多次DB查詢操作或者是一次請求返回大量的資料，加速系統資源消耗，從而拖垮後端的業務處理系統，甚至連相關儲存以及日誌收集系統也無法倖免。網上也有大量的免費IP網站，攻擊者可以大量的在網上收集 積累。
常見安全演算法—數字摘要
數字摘要也稱為訊息摘要，它是一個唯一對應一個訊息或文字的固定長度的值，它由一個單向Hash函式對訊息進行計算而產生。如果訊息在傳遞的途中改變了，接收者通過對收到訊息採用相同的Hash重新計算，新產生的摘要與原摘要進行比較，就可知道訊息是否被篡改了，因此訊息摘要能夠驗證訊息的完整性。訊息摘要採用單向Hash函式將需要計算的內容"摘要"成固定長度的串，這個串亦稱為數字指紋。這個串有固定的長度，且不同的明文摘要成密文，其結果總是不同的(相對的)，而同樣的明文其摘要必定一致。這樣這串摘要便可成為驗證明文是否是"真身"的"指紋"了
常見安全演算法—常用數字摘要演算法：
MD5
MD5即Message Digest Algorithm 5(資訊摘要演算法5)，是數字摘要演算法一種實現，用於確保資訊傳輸完整性和一致性，摘要長度為128位。 MD5由MD4、 MD3、 MD2改進而來，主要增強演算法複雜度和不可逆性，該演算法因其普遍、穩定、快速的特點，在產業界得到了極為廣泛的使用，目前主流的程式語言普遍都已有MD5演算法實現。
SHA
SHA的全稱是Secure Hash Algorithm，即安全雜湊演算法。 1993年，安全雜湊演算法(SHA)由美國國家標準和技術協會（ NIST)提出，並作為聯邦資訊處理標準(FIPS PUB 180)公佈， 1995年又
釋出了一個修訂版FIPS PUB 180-1，通常稱之為SHA-1。 SHA-1是基於MD4演算法的，現在已成為公認的最安全的雜湊演算法之一，並被廣泛使用。SHA-1演算法生成的摘要資訊的長度為160位，由於生成的摘要資訊更長，運算的過程更加複雜，在相同的硬體上， SHA-1的執行速度比MD5更慢，但是也更為安全。
常見安全演算法—對稱加密
對稱加密演算法是應用較早的加密演算法，技術成熟。在對稱加密演算法中，資料傳送方將明文(原始資料)和加密金鑰一起經過特殊加密演算法處理後，生成複雜的加密密文進行傳送，資料接收方收到密文後，若想讀取原文，則需要使用加密使用的金鑰及相同演算法的逆演算法對加密的密文進行解密，才能使其恢復成可讀明文。在對稱加密演算法中，使用的金鑰只有一個，傳送和接收雙方都使用這個金鑰對資料進行加密和解密，這就要求加密和解密方事先都必須知道加密的金鑰。
DES演算法：
1973 年，美國國家標準局(NBS)在認識到建立資料保護標準既明顯又急迫的情況下，開始徵集聯邦資料加密標準的方案。 1975 年3月17日， NBS公佈了IBM公司提供的密碼演算法，以標準建議的形式在全國範圍內徵求意見。經過兩年多的公開討論之後， 1977 年7月15日， NBS宣佈
接受這建議，作為聯邦資訊處理標準46 號資料加密標準(Data Encryptin Standard)DES演算法屬於對稱加密演算法，明文按64位進行分組，金鑰長64位，但事實上只有56位參與DES運算(第8、 16、 24、 32、 40、 48、 56、 64位是校驗位，使得每個金鑰都有奇數個1),分組後的明文和56位的金鑰按位替代或交換的方法形成密文。由於計算機運算能力的增強，原版DES密碼的金鑰長度變得容易被暴力破解，因此演變出了3DES演算法。 3DES是DES向AES過渡的加密演算法，它使用3條56位的金鑰對資料進行三次加密，是DES的一個更安全的變形。
AES演算法：
AES的全稱是Advanced Encryption Standard，即高階加密標準，該演算法由比利時密碼學家Joan Daemen和Vincent Rijmen所設計，結合兩位作者的名字，又稱Rijndael加密演算法，是美國聯邦政府採用的一種對稱加密標準，這個標準用來替代原先的DES演算法，已經廣為全世界所使用，已然成為對稱加密演算法中最流行的演算法之一。AES演算法作為新一代的資料加密標準匯聚了強安全性、高效能、高效率、易用和靈活等優點，設計有三個金鑰長度:128,192,256位，比DES演算法的加密強度更高，更為安全。
常見安全演算法—非對稱加密
非對稱加密演算法又稱為公開金鑰加密演算法，它需要兩個金鑰，一個稱為公開金鑰(public key)，即公鑰，另一個稱為私有金鑰(private key)，即私鑰。公鑰與私鑰需要配對使用，如果用公鑰對資料進行加密，只有用對應的私鑰才能進行解密，而如果使用私鑰對資料進行加密，那麼只有用對應的公鑰才能進行解密