翻譯自：http://find-sec-bugs.github.io/bugs.htm
翻譯：聶心明

xml解析導致xxe漏洞

漏洞特徵：XXE_XMLSTREAMREADER
當xml解析程序收到不信任的輸入且如果xml解析程序支持外部實體解析的時候，那麼造成xml實體解析攻擊（xxe）
危害1：探測本地文件內容（xxe：xml 外部實體）

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]>
<foo>&xxe;</foo>

危害2：拒絕服務攻擊（xee：xml 外部實體膨脹）

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
[...]
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

解決方法：
爲了避免解析xml帶來的攻擊，你應該按照下面的示例代碼修改你的代碼
有漏洞的代碼：

public void parseXML(InputStream input) throws XMLStreamException {

    XMLInputFactory factory = XMLInputFactory.newFactory();
    XMLStreamReader reader = factory.createXMLStreamReader(input);
    [...]
}

禁用外部實體的解決方案：

public void parseXML(InputStream input) throws XMLStreamException {

    XMLInputFactory factory = XMLInputFactory.newFactory();
    factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false);
    XMLStreamReader reader = factory.createXMLStreamReader(input);
    [...]
}

禁用DTD的方案：

public void parseXML(InputStream input) throws XMLStreamException {

    XMLInputFactory factory = XMLInputFactory.newFactory();
    factory.setProperty(XMLInputFactory.SUPPORT_DTD, false);
    XMLStreamReader reader = factory.createXMLStreamReader(input);
    [...]
}

引用：
CWE-611: Improper Restriction of XML External Entity Reference (‘XXE’)
CERT: IDS10-J. Prevent XML external entity attacks
OWASP.org: XML External Entity (XXE) Processing
WS-Attacks.org: XML Entity Expansion
WS-Attacks.org: XML External Entity DOS
WS-Attacks.org: XML Entity Reference Attack
Identifying Xml eXternal Entity vulnerability (XXE)
JEP 185: Restrict Fetching of External XML Resources

xml解析導致xxe漏洞(XPathExpression)

漏洞特徵：XXE_XPATH
當xml解析程序收到不信任的輸入且如果xml解析程序支持外部實體解析的時候，那麼造成xml實體解析攻擊（xxe）
危害1：探測本地文件內容（xxe：xml 外部實體）

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]>
<foo>&xxe;</foo>

危害2：拒絕服務攻擊（xee：xml 外部實體膨脹）

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
[...]
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

解決方法：
爲了避免解析xml帶來的攻擊，你應該按照下面的示例代碼修改你的代碼
有漏洞的代碼：

DocumentBuilder builder = df.newDocumentBuilder();

XPathFactory xPathFactory = XPathFactory.newInstance();
XPath xpath = xPathFactory.newXPath();
XPathExpression xPathExpr = xpath.compile("/somepath/text()");

xPathExpr.evaluate(new InputSource(inputStream));

下面的兩個片段展示了可能的解決方案。你可以設置其中一個，或者兩個都設置

使用"Secure processing" 模式的解決方案

DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
df.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
DocumentBuilder builder = df.newDocumentBuilder();

[...]

xPathExpr.evaluate( builder.parse(inputStream) );

禁用DTD的解決方案：
通過禁用DTD，大多數的xxe攻擊都可以被避免

DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
DocumentBuilder builder = df.newDocumentBuilder();

[...]

xPathExpr.evaluate( builder.parse(inputStream) );

xml解析導致xxe漏洞(SAXParser)

漏洞特徵：XXE_SAXPARSER
當xml解析程序收到不信任的輸入且如果xml解析程序支持外部實體解析的時候，那麼造成xml實體解析攻擊（xxe）
危害1：探測本地文件內容（xxe：xml 外部實體）

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]>
<foo>&xxe;</foo>

危害2：拒絕服務攻擊（xee：xml 外部實體膨脹）

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
[...]
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

解決方法：
爲了避免解析xml帶來的攻擊，你應該按照下面的示例代碼修改你的代碼
有漏洞的代碼：

SAXParser parser = SAXParserFactory.newInstance().newSAXParser();

parser.parse(inputStream, customHandler);

下面的兩個片段展示了可能的解決方案。你可以使用其中一個，或者兩個都使用

使用"Secure processing" 模式的解決方案:
這個設置能保護你能避免拒絕服務攻擊和ssrf漏洞

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
SAXParser parser = spf.newSAXParser();

parser.parse(inputStream, customHandler);

禁用DTD的解決方案:
通過禁用DTD，大多數的xxe攻擊都可以被避免

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
SAXParser parser = spf.newSAXParser();

parser.parse(inputStream, customHandler);

xml解析導致xxe漏洞(XMLReader)

漏洞特徵：XXE_XMLREADER
當xml解析程序收到不信任的輸入且如果xml解析程序支持外部實體解析的時候，那麼造成xml實體解析攻擊（xxe）
危害1：探測本地文件內容（xxe：xml 外部實體）

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]>
<foo>&xxe;</foo>

危害2：拒絕服務攻擊（xee：xml 外部實體膨脹）

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
[...]
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

解決方法：
爲了避免解析xml帶來的攻擊，你應該按照下面的示例代碼修改你的代碼
有漏洞的代碼：

XMLReader reader = XMLReaderFactory.createXMLReader();
reader.setContentHandler(customHandler);
reader.parse(new InputSource(inputStream));

下面的兩個片段展示了可能的解決方案。你可以使用其中一個，或者兩個都使用

使用"Secure processing" 模式的解決方案:
這個設置能保護你能避免拒絕服務攻擊和ssrf漏洞

XMLReader reader = XMLReaderFactory.createXMLReader();
reader.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
reader.setContentHandler(customHandler);

reader.parse(new InputSource(inputStream));

禁用DTD的解決方案:
通過禁用DTD，大多數的xxe攻擊都可以被避免

XMLReader reader = XMLReaderFactory.createXMLReader();
reader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
reader.setContentHandler(customHandler);

reader.parse(new InputSource(inputStream));

xml解析導致xxe漏洞(DocumentBuilder)

漏洞特徵：XXE_DOCUMENT
當xml解析程序收到不信任的輸入且如果xml解析程序支持外部實體解析的時候，那麼造成xml實體解析攻擊（xxe）
危害1：探測本地文件內容（xxe：xml 外部實體）

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]>
<foo>&xxe;</foo>

危害2：拒絕服務攻擊（xee：xml 外部實體膨脹）

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
[...]
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

解決方法：
爲了避免解析xml帶來的攻擊，你應該按照下面的示例代碼修改你的代碼
有漏洞的代碼：

DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder();

Document doc = db.parse(input);

下面的兩個片段展示了可能的解決方案。你可以使用其中一個，或者兩個都使用

使用"Secure processing" 模式的解決方案:
這個設置能保護你能避免拒絕服務攻擊和ssrf漏洞

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
DocumentBuilder db = dbf.newDocumentBuilder();

Document doc = db.parse(input);

禁用DTD的解決方案:
通過禁用DTD，大多數的xxe攻擊都可以被避免

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
DocumentBuilder db = dbf.newDocumentBuilder();

Document doc = db.parse(input);

xml解析導致xxe漏洞(TransformerFactory)

漏洞特徵：XXE_DTD_TRANSFORM_FACTORY
當xml解析程序收到不信任的輸入且如果xml解析程序支持外部實體解析的時候，那麼造成xml實體解析攻擊（xxe）
危害1：探測本地文件內容（xxe：xml 外部實體）

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]>
<foo>&xxe;</foo>

危害2：拒絕服務攻擊（xee：xml 外部實體膨脹）

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
[...]
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

解決方法：
爲了避免解析xml帶來的攻擊，你應該按照下面的示例代碼修改你的代碼
有漏洞的代碼：

Transformer transformer = TransformerFactory.newInstance().newTransformer();
transformer.transform(input, result);

下面的兩個片段展示了可能的解決方案。你可以使用其中一個，或者兩個都使用

使用"Secure processing" 模式的解決方案:
這個設置能保護你能避免拒絕服務攻擊和ssrf漏洞

TransformerFactory factory = TransformerFactory.newInstance();
factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "all");
factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "all");

Transformer transformer = factory.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");

transformer.transform(input, result);

禁用DTD的解決方案:
通過禁用DTD，大多數的xxe攻擊都可以被避免

TransformerFactory factory = TransformerFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

Transformer transformer = factory.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");

transformer.transform(input, result);

XSLT解析導致xxe漏洞(TransformerFactory)

漏洞特徵：XXE_XSLT_TRANSFORM_FACTORY
當xml解析程序收到不信任的輸入且如果xml解析程序支持外部實體解析的時候，那麼造成xml實體解析攻擊（xxe）
危害1：探測本地文件內容（xxe：xml 外部實體）

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
   <xsl:template match="/">
       <xsl:value-of select="document('/etc/passwd')">
   </xsl:value-of></xsl:template>
</xsl:stylesheet>

解決方法：
爲了避免解析xml帶來的攻擊，你應該按照下面的示例代碼修改你的代碼
有漏洞的代碼：

Transformer transformer = TransformerFactory.newInstance().newTransformer();
transformer.transform(input, result);

下面的兩個片段展示了可能的解決方案。你可以使用其中一個，或者兩個都使用

使用"Secure processing" 模式的解決方案:
這個設置能保護你能避免ssrf漏洞但是不能避免拒絕服務攻擊

TransformerFactory factory = TransformerFactory.newInstance();
factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "all");
factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "all");

Transformer transformer = factory.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");

transformer.transform(input, result);

禁用DTD的解決方案:
這個設置能保護你能避免ssrf漏洞但是不能避免拒絕服務攻擊

TransformerFactory factory = TransformerFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

Transformer transformer = factory.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");

transformer.transform(input, result);

潛在的XPath注入

漏洞特徵： XPATH_INJECTION
XPath注入的危險程度就像sql注入一樣。如果XPath查詢包含不信任的用戶輸入，那麼數據庫就會被完全暴露。這樣就可以讓攻擊者訪問未授權的數據或者在目標xml數據庫中放入惡意數據。

引用：
WASC-39: XPath Injection
OWASP: Top 10 2013-A1-Injection
CWE-643: Improper Neutralization of Data within XPath Expressions (‘XPath Injection’)
CERT: IDS09-J. Prevent XPath Injection (archive)
Black Hat Europe 2012: Hacking XPath 2.0
Balisage: XQuery Injection

發現Struts 1 服務器端

漏洞特徵： STRUTS1_ENDPOINT
這個類是Struts 1 的Action
曾清一個請求被路由到一個控制器中，Form對象將會被自動的實例化爲http參數的對象。這些參數應該被嚴格檢查，以保證它們是安全的。

發現Struts 2 服務器端

漏洞特徵：STRUTS2_ENDPOINT
在Struts 2中，服務器端是簡單的Java對象 (POJOs)，這就意味着沒有接口/類需要被實現/拓展

當一個請求被路由到它的控制器的時候（像這些被選擇的類），http提供的參數會被自動的映射到類中的setters中。所以，所有類中的setters都應該被看成來自不被信任源的輸入，即使form中沒有包含那些值。一個攻擊者都被在請求中插入一些額外的值，他們會被當成對象，只要對象具有這樣的setter。這些參數應該被嚴格檢查，以保證它們是安全的。

發現Spring 服務器端

漏洞特徵： SPRING_ENDPOINT
這個類是一個Spring的控制器。所有方法的註解都在RequestMapping（還有一些簡化註解在GetMapping, PostMapping, PutMapping, DeleteMapping, 和 PatchMapping），這些方法都能被遠程訪問到。這些類應該被嚴格的分析，以保證暴露給遠程的方法是安全的，不會被攻擊者輕易攻擊。

Spring關閉 CSRF保護

漏洞特徵： SPRING_CSRF_PROTECTION_DISABLED
對於標準的web應用程序來講，關閉Spring的CSRF保護顯然是不安全的。
禁用此保護的有效使用場景是服務器暴露一個可以改變狀態的接口，這個接口僅可以被非瀏覽器操控。

不安全的配置

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable();
    }
}

引用：
Spring Security Official Documentation: When to use CSRF protection
OWASP: Cross-Site Request Forgery
OWASP: CSRF Prevention Cheat Sheet
CWE-352: Cross-Site Request Forgery (CSRF)

Spring 中不受CSRF限制的RequestMapping

漏洞特徵： SPRING_CSRF_UNRESTRICTED_REQUEST_MAPPING
通過默認的映射所有的HTTP請求方法都會被RequestMapping註解。可是，http請求中的GET, HEAD, TRACE, 和OPTIONS（可能會導致tokens被泄露）方法不會默認開啓csrf保護。所以，被RequestMapping註解的可以改變狀態的方法和 POST, PUT, DELETE, 或者 PATCH這些http請求方法都會受到csrf攻擊。

有漏洞的代碼：

@Controller
public class UnsafeController {

    @RequestMapping("/path")
    public void writeData() {
        // State-changing operations performed within this method.
    }
}

解決方案（Spring Framework 4.3和更新的版本）

@Controller
public class SafeController {

    /**
     * For methods without side-effects use @GetMapping.
     */
    @GetMapping("/path")
    public String readData() {
        // No state-changing operations performed within this method.
        return "";
    }

    /**
     * For state-changing methods use either @PostMapping, @PutMapping, @DeleteMapping, or @PatchMapping.
     */
    @PostMapping("/path")
    public void writeData() {
        // State-changing operations performed within this method.
    }
}

解決方案（在Spring Framework 4.3之前的版本）

@Controller
public class SafeController {

    /**
     * For methods without side-effects use either
     * RequestMethod.GET, RequestMethod.HEAD, RequestMethod.TRACE, or RequestMethod.OPTIONS.
     */
    @RequestMapping(value = "/path", method = RequestMethod.GET)
    public String readData() {
        // No state-changing operations performed within this method.
        return "";
    }

    /**
     * For state-changing methods use either
     * RequestMethod.POST, RequestMethod.PUT, RequestMethod.DELETE, or RequestMethod.PATCH.
     */
    @RequestMapping(value = "/path", method = RequestMethod.POST)
    public void writeData() {
        // State-changing operations performed within this method.
    }
}

引用：
[Spring Security Official Documentation: Use proper HTTP verbs (CSRF protection)](Spring Security Official Documentation: Use proper HTTP verbs (CSRF protection))
[OWASP: Cross-Site Request Forgery](OWASP: Cross-Site Request Forgery)
OWASP: CSRF Prevention Cheat Sheet
CWE-352: Cross-Site Request Forgery (CSRF)

潛在的注入（custom）

漏洞特徵： CUSTOM_INJECTION
掃描工具所識別的函數存在注射問題。應驗證輸入並爭取轉義。

有漏洞的代碼：

SqlUtil.execQuery("select * from UserEntity t where id = " + parameterInput);

wiki在線有很詳細的教程關於如何配置custom

引用：
WASC-19: SQL Injection
OWASP: Top 10 2013-A1-Injection
OWASP: SQL Injection Prevention Cheat Sheet
OWASP: Query Parameterization Cheat Sheet
CAPEC-66: SQL Injection
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)

潛在的sql注入

漏洞特徵：SQL_INJECTION
輸入進sql查詢的數據應該通過嚴格的檢查。在預編譯中綁定參數可以更容易的緩解sql注入帶來的危害。或者，每一個參數應該被正確的轉義。
有漏洞的代碼：

createQuery("select * from User where id = '"+inputId+"'");

解決方案：

import org.owasp.esapi.Encoder;

createQuery("select * from User where id = '"+Encoder.encodeForSQL(inputId)+"'");

引用（sql注入）
WASC-19: SQL Injection
CAPEC-66: SQL Injection
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
OWASP: Top 10 2013-A1-Injection
OWASP: SQL Injection Prevention Cheat Sheet
OWASP: Query Parameterization Cheat Sheet

在Turbine中潛在的sql注入

漏洞特徵：SQL_INJECTION_TURBINE
輸入進sql查詢的數據應該通過嚴格的檢查。在預編譯中綁定參數可以更容易的緩解sql注入帶來的危害。或者，每一個參數應該被正確的轉義。
Turbine API 提供DSL在java代碼中構建查詢
有漏洞的代碼：

List<Record> BasePeer.executeQuery( "select * from Customer where id=" + inputId );

解決方案（使用Criteria DSL）：

Criteria c = new Criteria();
c.add( CustomerPeer.ID, inputId );

List<Customer> customers = CustomerPeer.doSelect( c );

解決方案（使用特殊方法）：

Customer customer = CustomerPeer.retrieveByPK( new NumberKey( inputId ) );

解決方法（使用OWASP提供的編碼方法）

import org.owasp.esapi.Encoder;

BasePeer.executeQuery("select * from Customer where id = '"+Encoder.encodeForSQL(inputId)+"'");

引用(Turbine)：
Turbine Documentation: Criteria Howto
引用（sql注入）
WASC-19: SQL Injection
CAPEC-66: SQL Injection
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
OWASP: Top 10 2013-A1-Injection
OWASP: SQL Injection Prevention Cheat Sheet
OWASP: Query Parameterization Cheat Sheet

潛在的SQL/HQL注入(Hibernate)

漏洞特徵：SQL_INJECTION_HIBERNATE
輸入進sql查詢的數據應該通過嚴格的檢查。在預編譯中綁定參數可以更容易的緩解sql注入帶來的危害。或者，可以使用Hibernate的Criteria。
有漏洞的代碼：

Session session = sessionFactory.openSession();
Query q = session.createQuery("select t from UserEntity t where id = " + input);
q.execute();

解決方案：

Session session = sessionFactory.openSession();
Query q = session.createQuery("select t from UserEntity t where id = :userId");
q.setString("userId",input);
q.execute();

動態查詢參數法解決方案（Hibernate Criteria）

Session session = sessionFactory.openSession();
Query q = session.createCriteria(UserEntity.class)
    .add( Restrictions.like("id", input) )
    .list();
q.execute();

引用(Hibernate)
Hibernate Documentation: Query Criteria
Hibernate Javadoc: Query Object
HQL for pentesters: Guideline to test if the suspected code is exploitable.
引用（sql注入）
WASC-19: SQL Injection
CAPEC-66: SQL Injection
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
OWASP: Top 10 2013-A1-Injection
OWASP: SQL Injection Prevention Cheat Sheet
OWASP: Query Parameterization Cheat Sheet

潛在的sql/JDOQL注入(JDO)

漏洞特徵：SQL_INJECTION_JDO
輸入進sql查詢的數據應該通過嚴格的檢查。在預編譯中綁定參數可以更容易的緩解sql注入帶來的危害。
有漏洞的代碼：

PersistenceManager pm = getPM();

Query q = pm.newQuery("select * from Users where name = " + input);
q.execute();

解決方案：

PersistenceManager pm = getPM();

Query q = pm.newQuery("select * from Users where name = nameParam");
q.declareParameters("String nameParam");
q.execute(input);

引用(JDO)：
JDO: Object Retrieval
引用（sql注入）
WASC-19: SQL Injection
CAPEC-66: SQL Injection
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
OWASP: Top 10 2013-A1-Injection
OWASP: SQL Injection Prevention Cheat Sheet
OWASP: Query Parameterization Cheat Sheet

潛在的sql/JPQL注入(JPA)

漏洞特徵： SQL_INJECTION_JPA
輸入進sql查詢的數據應該通過嚴格的檢查。在預編譯中綁定參數可以更容易的緩解sql注入帶來的危害。
有漏洞的代碼：

EntityManager pm = getEM();

TypedQuery<UserEntity> q = em.createQuery(
    String.format("select * from Users where name = %s", username),
    UserEntity.class);

UserEntity res = q.getSingleResult();

解決方案：

TypedQuery<UserEntity> q = em.createQuery(
    "select * from Users where name = usernameParam",UserEntity.class)
    .setParameter("usernameParam", username);

UserEntity res = q.getSingleResult();

引用 (JPA)
The Java EE 6 Tutorial: Creating Queries Using the Java Persistence Query Language
引用（sql注入）
WASC-19: SQL Injection
CAPEC-66: SQL Injection
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
OWASP: Top 10 2013-A1-Injection
OWASP: SQL Injection Prevention Cheat Sheet
OWASP: Query Parameterization Cheat Sheet

潛在的JDBC注入(Spring JDBC)

漏洞特徵：SQL_INJECTION_SPRING_JDBC
輸入進sql查詢的數據應該通過嚴格的檢查。在預編譯中綁定參數可以更容易的緩解sql注入帶來的危害。或者，每一個參數應該被正確的轉義。
有漏洞的代碼：

JdbcTemplate jdbc = new JdbcTemplate();
int count = jdbc.queryForObject("select count(*) from Users where name = '"+paramName+"'", Integer.class);

解決方案：

JdbcTemplate jdbc = new JdbcTemplate();
int count = jdbc.queryForObject("select count(*) from Users where name = ?", Integer.class, paramName);

引用 (Spring JDBC)
Spring Official Documentation: Data access with JDBC
引用（sql注入）
WASC-19: SQL Injection
CAPEC-66: SQL Injection
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
OWASP: Top 10 2013-A1-Injection
OWASP: SQL Injection Prevention Cheat Sheet
OWASP: Query Parameterization Cheat Sheet

潛在的JDBC注入

漏洞特徵：SQL_INJECTION_JDBC
輸入進sql查詢的數據應該通過嚴格的檢查。在預編譯中綁定參數可以更容易的緩解sql注入帶來的危害。
有漏洞的代碼：

Connection conn = [...];
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("update COFFEES set SALES = "+nbSales+" where COF_NAME = '"+coffeeName+"'");

解決方案：

Connection conn = [...];
conn.prepareStatement("update COFFEES set SALES = ? where COF_NAME = ?");
updateSales.setInt(1, nbSales);
updateSales.setString(2, coffeeName);

引用 (JDBC)
Oracle Documentation: The Java Tutorials > Prepared Statements
引用（sql注入）
WASC-19: SQL Injection
CAPEC-66: SQL Injection
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
OWASP: Top 10 2013-A1-Injection
OWASP: SQL Injection Prevention Cheat Sheet
OWASP: Query Parameterization Cheat Sheet

潛在的Scala Slick注入

漏洞特徵：SCALA_SQL_INJECTION_SLICK
輸入進sql查詢的數據應該通過嚴格的檢查。在預編譯中綁定參數可以更容易的緩解sql注入帶來的危害。
有漏洞的代碼：

db.run {
  sql"select * from people where name = '#$value'".as[Person]
}

解決方案：

db.run {
  sql"select * from people where name = $value".as[Person]
}

潛在的Scala Anorm注入

漏洞特徵：SCALA_SQL_INJECTION_ANORM
輸入進sql查詢的數據應該通過嚴格的檢查。在預編譯中綁定參數可以更容易的緩解sql注入帶來的危害。
有漏洞的代碼：

val peopleParser = Macro.parser[Person]("id", "name", "age")

DB.withConnection { implicit c =>
  val people: List[Person] = SQL("select * from people where name = '" + value + "'").as(peopleParser.*)
}

解決方案：

val peopleParser = Macro.parser[Person]("id", "name", "age")

DB.withConnection { implicit c =>
  val people: List[Person] = SQL"select * from people where name = $value".as(peopleParser.*)
}

潛在的安卓sql注入

漏洞特徵：SQL_INJECTION_ANDROID
輸入進sql查詢的數據應該通過嚴格的檢查。在預編譯中綁定參數可以更容易的緩解sql注入帶來的危害。
有漏洞的代碼：

String query = "SELECT * FROM  messages WHERE uid= '"+userInput+"'" ;
Cursor cursor = this.getReadableDatabase().rawQuery(query,null);

解決方案：

String query = "SELECT * FROM  messages WHERE uid= ?" ;
Cursor cursor = this.getReadableDatabase().rawQuery(query,new String[] {userInput});

引用 (Android SQLite)
InformIT.com: Practical Advice for Building Secure Android Databases in SQLite
Packtpub.com: Knowing the SQL-injection attacks and securing our Android applications from them

Android Database Support (Enterprise Android: Programming Android Database Applications for the Enterprise)

Safe example of Insert, Select, Update and Delete queryies provided by Suragch

潛在的LDAP注入

漏洞特徵：LDAP_INJECTION
就像sql，所有進入到ldap查詢的語句都必須要保證安全。不幸的是，ldap沒有像sql那樣的預編譯接口。所以，現在的主要防禦方式是，在參數進入ladp查詢之前對其進行嚴格的檢驗。
有漏洞的代碼：

NamingEnumeration<SearchResult> answers = context.search("dc=People,dc=example,dc=com",
        "(uid=" + username + ")", ctrls);

引用：
WASC-29: LDAP Injection
OWASP: Top 10 2013-A1-Injection
CWE-90: Improper Neutralization of Special Elements used in an LDAP Query (‘LDAP Injection’)
LDAP Injection Guide: Learn How to Detect LDAP Injections and Improve LDAP Security

java代碼審計手書(二）

xml解析導致xxe漏洞

xml解析導致xxe漏洞(XPathExpression)

xml解析導致xxe漏洞(SAXParser)

xml解析導致xxe漏洞(XMLReader)

xml解析導致xxe漏洞(DocumentBuilder)

xml解析導致xxe漏洞(TransformerFactory)

XSLT解析導致xxe漏洞(TransformerFactory)

潛在的XPath注入

發現Struts 1 服務器端

發現Struts 2 服務器端

發現Spring 服務器端

Spring關閉 CSRF保護

Spring 中不受CSRF限制的RequestMapping

潛在的注入（custom）

潛在的sql注入

在Turbine中潛在的sql注入

潛在的SQL/HQL注入(Hibernate)

潛在的sql/JDOQL注入(JDO)

潛在的sql/JPQL注入(JPA)

潛在的JDBC注入(Spring JDBC)

潛在的JDBC注入

潛在的Scala Slick注入

潛在的Scala Anorm注入

潛在的安卓sql注入

潛在的LDAP注入

如何使用 JS 判斷用戶是否處於活躍狀態

通過HPA+CronHPA組合應對業務複雜彈性伸縮場景

java readobject源碼解讀和反序列化分析

使用ysoserial生成反序列化文件

一道有趣的關於nodejs的ctf題

使用APM破解Imminent rat病毒後我們學到的東西

通過AMPScript 來收集Uber的用戶數據

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結