JSP / 서블릿 웹 애플리케이션에서 XSS 방지

JSP / 서블릿 웹 애플리케이션에서 XSS 방지

---

JSP / 서블릿 웹 애플리케이션에서 XSS 공격을 어떻게 방지 할 수 있습니까?

---

사용자 제어 입력을 (재) 표시 할 때 JSTL <c:out> 태그 또는 fn:escapeXml()EL 함수 를 사용하여 JSP에서 XSS를 방지 할 수 있습니다 . 여기에는 요청 매개 변수, 헤더, 쿠키, URL, 본문 등이 포함됩니다. 요청 객체에서 추출한 모든 것. 또한 데이터베이스에 저장된 이전 요청의 사용자 제어 입력은 다시 표시하는 동안 이스케이프되어야합니다.

예를 들면 :

<p><c:out value="${bean.userControlledValue}"></p>
<p><input name="foo" value="${fn:escapeXml(param.foo)}"></p>

이 같은 렌더링 된 HTML을 malform 수있는 문자 탈출 것 <, >, ", '과 &에 HTML / XML 엔티티 등 <, >, ", '와 &.

Java (서블릿) 코드에서 이스케이프 할 필요는 없습니다. 일부는 동안을 탈출 선택할 수 있습니다 요청 (당신은 서블릿 또는 필터에서처럼) 대신 처리 응답 예 ((당신이 JSP에서와 같이) 처리하지만,이 방법은 데이터가 불필요하게 이중 이스케이프 얻을 위험이 있습니다 &하게 &대신 &하고 궁극적으로 최종 사용자는&또는 DB에 저장된 데이터를 이식 할 수 없게되는 경우 (예 : HTML 이스케이프가 전혀 필요하지 않은 JSON, CSV, XLS, PDF 등으로 데이터를 내보낼 때). 또한 사용자가 실제로 무엇을 입력했는지 더 이상 알지 못하기 때문에 사회적 통제를 잃게됩니다. 사이트 관리자는 XSS를 수행하려는 사용자 / IP를 알고 싶어하므로 쉽게 추적 할 수 있습니다. 그에 따라 조치를 취하십시오. 요청 처리 중 이스케이프는 가능한 한 최단 시간에 잘못 개발 된 레거시 웹 애플리케이션의 열차 난파선을 수정해야하는 경우에만 최신 수단으로 사용해야합니다. 그래도 궁극적으로 JSP 파일을 다시 작성하여 XSS 안전이되도록해야합니다.

당신은 당신이 HTML 태그 등의 특정 부분 집합을 허용하고자하는 것을 특징으로 HTML로 사용자 제어 입력을 다시 표시하려는 경우 <b>, <i>, <u>, 등, 당신은 화이트리스트에 의해 입력을 소독해야합니다. 이를 위해 Jsoup 과 같은 HTML 파서를 사용할 수 있습니다 . 그러나 훨씬 더 나은 방법은 Markdown (여기 Stack Overflow에서도 사용됨)과 같은 인간 친화적 인 마크 업 언어를 도입하는 것입니다. 그런 다음 CommonMark 와 같은 Markdown 파서를 사용할 수 있습니다 . HTML 삭제 기능도 내장되어 있습니다. I 'm looking for a Java HTML encoder 도 참조하십시오 .

데이터베이스와 관련하여 서버 측의 유일한 관심사는 SQL 주입 방지입니다. SQL 또는 JPQL 쿼리에서 사용자 제어 입력을 직접 문자열 연결하지 않고 매개 변수가있는 쿼리를 계속 사용하고 있는지 확인해야합니다. JDBC의 측면에서,이 방법은 당신이 사용해야하는 PreparedStatement대신 Statement. JPA 용어로 Query.

---

대안은 JSP / Servlet에서 Java EE의 MVC 프레임 워크 JSF 로 마이그레이션하는 것 입니다. 모든 곳에서 XSS (및 CSRF!) 방지 기능이 내장되어 있습니다. JSF의 CSRF, XSS 및 SQL Injection 공격 방지를 참조하십시오 .

---

xss를 방지하는 방법이 여러 번 요청되었습니다. StackOverflow에서 많은 정보를 찾을 수 있습니다. 또한 OWASP 웹 사이트에는 통과해야 할 XSS 방지 치트 시트 가 있습니다.

사용할 라이브러리에서 OWASP의 ESAPI 라이브러리 에는 자바 풍미가 있습니다. 당신은 그것을 시도해야합니다. 그 외에도 사용하는 모든 프레임 워크에는 XSS에 대한 보호 기능이 있습니다. 다시 말하지만 OWASP 웹 사이트에는 가장 인기있는 프레임 워크에 대한 정보가 있으므로 해당 사이트를 살펴 보는 것이 좋습니다.

---

OWASP Anti-Samy와 XSS가 들어오는 것을 차단하는 모든 Spring 컨트롤러의 AspectJ 고문과 함께 큰 행운을 얻었습니다.

public class UserInputSanitizer {

    private static Policy policy;
    private static AntiSamy antiSamy;

    private static AntiSamy getAntiSamy() throws PolicyException  {
        if (antiSamy == null) {
            policy = getPolicy("evocatus-default");
            antiSamy = new AntiSamy();
        }
        return antiSamy;

    }

    public static String sanitize(String input) {
        CleanResults cr;
        try {
            cr = getAntiSamy().scan(input, policy);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
        return cr.getCleanHTML();
    }

    private static Policy getPolicy(String name) throws PolicyException {
        Policy policy = 
            Policy.getInstance(Policy.class.getResourceAsStream("/META-INF/antisamy/" + name + ".xml"));
        return policy;
    }

}

이 stackoverflow 게시물 에서 AspectJ 권고자를 얻을 수 있습니다.

나는 이것이 자바 스크립트를 많이 사용하는 경우 특히 c : out보다 더 나은 접근 방식이라고 생각합니다.

---

Managing XSS requires multiple validations, data from the client side.

1. Input Validations (form validation) on the Server side. There are multiple ways of going about it. You can try JSR 303 bean validation(hibernate validator), or ESAPI Input Validation framework. Though I've not tried it myself (yet), there is an annotation that checks for safe html (@SafeHtml). You could in fact use Hibernate validator with Spring MVC for bean validations -> Ref
2. Escaping URL requests - For all your HTTP requests, use some sort of XSS filter. I've used the following for our web app and it takes care of cleaning up the HTTP URL request - http://www.servletsuite.com/servlets/xssflt.htm
3. Escaping data/html returned to the client (look above at @BalusC explanation).

---

I would suggest regularly testing for vulnerabilities using an automated tool, and fixing whatever it finds. It's a lot easier to suggest a library to help with a specific vulnerability then for all XSS attacks in general.

Skipfish is an open source tool from Google that I've been investigating: it finds quite a lot of stuff, and seems worth using.

---

There is no easy, out of the box solution against XSS. The OWASP ESAPI API has some support for the escaping that is very usefull, and they have tag libraries.

My approach was to basically to extend the stuts 2 tags in following ways.

1. Modify s:property tag so it can take extra attributes stating what sort of escaping is required (escapeHtmlAttribute="true" etc.). This involves creating a new Property and PropertyTag classes. The Property class uses OWASP ESAPI api for the escaping.
2. Change freemarker templates to use the new version of s:property and set the escaping.

If you didn't want to modify the classes in step 1, another approach would be to import the ESAPI tags into the freemarker templates and escape as needed. Then if you need to use a s:property tag in your JSP, wrap it with and ESAPI tag.

I have written a more detailed explanation here.

http://www.nutshellsoftware.org/software/securing-struts-2-using-esapi-part-1-securing-outputs/

I agree escaping inputs is not ideal.

---

My personal opinion is that you should avoid using JSP/ASP/PHP/etc pages. Instead output to an API similar to SAX (only designed for calling rather than handling). That way there is a single layer that has to create well formed output.

---

If you want to automatically escape all JSP variables without having to explicitly wrap each variable, you can use an EL resolver as detailed here with full source and an example (JSP 2.0 or newer), and discussed in more detail here:

For example, by using the above mentioned EL resolver, your JSP code will remain like so, but each variable will be automatically escaped by the resolver

...
<c:forEach items="${orders}" var="item">
  <p>${item.name}</p>
  <p>${item.price}</p>
  <p>${item.description}</p>
</c:forEach>
...

If you want to force escaping by default in Spring, you could consider this as well, but it doesn't escape EL expressions, just tag output, I think:

http://forum.springsource.org/showthread.php?61418-Spring-cross-site-scripting&p=205646#post205646

Note: Another approach to EL escaping that uses XSL transformations to preprocess JSP files can be found here:

http://therning.org/niklas/2007/09/preprocessing-jsp-files-to-automatically-escape-el-expressions/

참고URL : https://stackoverflow.com/questions/2658922/xss-prevention-in-jsp-servlet-web-application