JSF에서 CSRF, XSS 및 SQL 주입 공격 방지

JSF에서 CSRF, XSS 및 SQL 주입 공격 방지

---

MySQL을 DB로 사용하여 JSF에 구축 된 웹 애플리케이션이 있습니다. 내 애플리케이션에서 CSRF를 방지하는 코드를 이미 구현했습니다.

이제 내 기본 프레임 워크가 JSF이므로 XSS 공격이 이미 .NET에서 처리되므로 처리 할 필요가 없다고 생각합니다 UIComponent. 보기 페이지에서 JavaScript를 사용하고 있지 않습니다. 내가 사용하더라도 XSS 공격을 방지하기위한 코드를 구현해야합니까?

DB의 경우 모든 DB 상호 작용에서 준비된 문과 저장 프로 시저를 사용합니다.

이 3 가지 일반적인 공격을 방지하기 위해 처리해야 할 다른 사항이 있습니까? 나는 이미 OWASP 사이트와 그들의 치트 시트를 살펴 보았다 .

다른 잠재적 인 공격 벡터를 처리해야합니까?

---

XSS

JSF는 XSS 방지 기능이 내장되도록 설계되었습니다. JSF 컴포넌트를 사용하여 모든 사용자 제어 입력 (요청 헤더 (쿠키 포함!), 요청 매개 변수 (DB에 저장된 것!) 및 요청 본문 (업로드 된 텍스트 파일 등))을 안전하게 다시 표시 할 수 있습니다 .

<h:outputText value="#{user.name}" />
<h:outputText value="#{user.name}" escape="true" />
<h:inputText value="#{user.name}" />
etc...

Facelets에서 JSF 2.0을 사용할 때 다음과 같이 템플릿 텍스트에서 EL을 사용할 수 있습니다.

<p>Welcome, #{user.name}</p>

이것은 또한 암시 적으로 이스케이프됩니다. <h:outputText>여기에 반드시 필요한 것은 아닙니다 .

다음을 사용하여 사용자 제어 입력을 명시 적으로 이스케이프 해제하는 경우 에만escape="false" :

<h:outputText value="#{user.name}" escape="false" />

그러면 잠재적 인 XSS 공격 구멍이 있습니다!

당신은 당신이 HTML 태그 등의 특정 부분 집합을 허용하고자하는 것을 특징으로 HTML로 사용자 제어 입력을 다시 표시하려는 경우 <b>, <i>, <u>, 등, 당신은 화이트리스트에 의해 입력을 소독해야합니다. HTML 파서 Jsoup 은 이것에 매우 유용 합니다.

itemLabelEscaped Mojarra <2.2.6의 버그

이전 페이지 인 Mojarra 버전 전에 2.2.6 상기 버그했다 <f:selectItems itemLabel>제공 때 잘못 라벨 이스케이프 렌더링 List<T>을 통해 <f:selectItems var>대신 List<SelectItem>또는 SelectItem[]값 (같은 문제를 3143 ). 즉, 사용자 제어 데이터를를 통해 항목 레이블로 다시 표시 List<T>하는 경우 잠재적 인 XSS 구멍이 있습니다. Mojarra 2.2.6 이상으로 업그레이드하는 것이 옵션이 아닌 경우 이를 방지하기 위해 명시 적으로 itemLabelEscaped속성을 true로 설정해야 합니다.

<f:selectItems value="#{bean.entities}" var="entity" itemValue="#{entity}"
    itemLabel="#{entity.someUserControlledProperty}" itemLabelEscaped="true" />

---

CSRF

JSF 2.x는 javax.faces.ViewState서버 측 상태 저장을 사용할 때 양식 의 숨겨진 필드에 이미 CSRF 방지 기능을 내장하고 있습니다 . JSF 1.x에서이 값은 매우 약하고 너무 쉽게 예측할 수있었습니다 (실제로 CSRF 방지로 의도 된 것이 아님). JSF 2.0에서는 예측 가능한 시퀀스 값 대신 길고 강력한 자동 생성 값을 사용하여 개선되어 강력한 CSRF 방지 기능을 제공합니다.

JSF 2.2에서는 클라이언트 측 상태 저장이 활성화 된 경우 클라이언트 측 상태를 암호화하기 위해 구성 가능한 AES 키와 함께 JSF 사양의 필수 부분으로 만들어 더욱 개선되었습니다. JSF 사양 문제 869 및 다른 세션 (CSRF)에서 ViewState 값 재사용을 참조하십시오 . JSF 2.2의 새로운 기능은 .NET의 GET 요청에 대한 CSRF 보호입니다 <protected-views>.

에서 <f:view transient="true">와 같이 상태 비 저장보기를 사용 하거나 애플리케이션에 XSS 공격 구멍이있는 경우에만 잠재적 인 CSRF 공격 구멍이 있습니다.

---

SQL 주입

이것은 JSF의 책임이 아닙니다. 이를 방지하는 방법은 사용중인 지속성 API (원시 JDBC, 최신 JPA 또는 우수한 Hibernate)에 따라 다르지만 사용자 제어 입력을 SQL 문자열에 연결 해서는 안된다는 결론이 나옵니다.

String sql = "SELECT * FROM user WHERE username = '" + username + "' AND password = md5(" + password + ")";
String jpql = "SELECT u FROM User u WHERE u.username = '" + username + "' AND u.password = md5('" + password + "')";

최종 사용자가 다음 이름을 선택하면 어떻게되는지 상상해보십시오.

x'; DROP TABLE user; --

당신은해야한다 항상 적용 가능한 매개 변수화 된 쿼리를 사용합니다.

String sql = "SELECT * FROM user WHERE username = ? AND password = md5(?)";
String jpql = "SELECT u FROM User u WHERE u.username = ?1 AND u.password = md5(?2)";

일반 JDBC에서는 PreparedStatement매개 변수 값을 채우는 데 사용해야 하며 JPA (및 Hibernate)에서도 Query객체가이를위한 setter를 제공합니다.

---

보기 페이지에서 JavaScript를 사용하고 있지 않습니다. 내가 사용하더라도 XSS 공격을 우회하는 코드를 구현해야합니다.

페이지에서 JavaScript를 사용하지 않더라도 XSS에 취약 할 수 있습니다. XSS는 적절한 인코딩없이 공격자가 제어하는 ​​콘텐츠를 통합 할 때 발생합니다.

당신이 뭔가를 할 때마다

response.write("<b>" + x + "</b>")

공격자 x가 JavaScript가 포함 된 HTML을 포함하도록 만들 수있는 경우 XSS에 취약합니다.

해결책은 일반적으로 많은 양의 코드를 작성하지 않는 것입니다. 일반적으로 솔루션은 $x생성하는 HTML에 포함하기 전에 공격자가 제어하는 ​​다른 값과 인코딩하는 것입니다.

response.write("<b>" + escapePlainTextToHtml(x) + "</b>")

입력을 필터링하거나 삭제하면 추가 보호 계층을 제공 할 수 있습니다.

<shameless-plug>

XSS로부터 보호하기 위해 출력을 자동으로 인코딩하는 템플릿 언어를 사용할 수도 있습니다.

Closure Template is one such option for Java.

Contextual autoescaping works by augmenting Closure Templates to properly encode each dynamic value based on the context in which it appears, thus defending against XSS vulnerabilities in values that are controlled by an attacker.

EDIT

Since you are using JSF you should read up on XSS mitigation in JSF:

Escape output text

<h:outputText/> and <h:outputLabel/> by default has the escape attribute set to True. By using this tag to display outputs, you are able to mitigate majority of the XSS vulnerability.

SeamTextParser and <s:formattedText/>

If you would like to allow users to utilise some of the basic html tags to customise their inputs, JBoss Seam provides a <s:formattedText/> tag that allows some basic html tags and styles specified by users.

---

When using <h:outputText escape="false"> with unescaped values (for example coming from html text editors) you're open for a nasty XSS attacks. In such cases I'm using a JSF converter which uses Jsoup to remove javascript from text leaving HTML intact. Converter can be used to sanitize user inputs as well. You can use it like this:

<h:outputText value="{bean.value}" escape="false" converter="htmlSanitizingConverter"/>

And the converter itself:

/**
 * Prevents from XSS attack if output text is not escaped.
 */
@FacesConverter("htmlSanitizingConverter")
public class HtmlSanitizingConverter implements Converter {

    private static final Whitelist JSOUP_WHITELIST = Whitelist.relaxed()
            .preserveRelativeLinks(true)
            .addAttributes(":all","style");
            /*
             Optionally - add support for hyperlinks and base64 encoded images.
            .addTags("img")
            .addAttributes("img", "height", "src", "width")
            .addAttributes("a", "href")
            .addProtocols("img", "src", "http", "https", "data");
            */

    @Override
    public Object getAsObject(FacesContext context, UIComponent component, String submittedValue) {
        return (submittedValue != null) ? Jsoup.clean(submittedValue, JSOUP_WHITELIST) : null;
    }

    @Override
    public String getAsString(FacesContext context, UIComponent component, Object value) {
        return (value != null) ? Jsoup.clean(value.toString(), JSOUP_WHITELIST) : "";
    }

}

Note: When you're using JSF with PrimeFaces, beware of <p:textEditor> - older versions (prior to 6.2) by default didn't sanitize user input.

ReferenceURL : https://stackoverflow.com/questions/7722159/csrf-xss-and-sql-injection-attack-prevention-in-jsf