본문 바로가기
2/Security

파일 업로드 기능을 구현하는 것이 왜 보안적인 관점에서 좋지 않은가?

by berry-hi 2020. 10. 15.

가끔 기능중에 "웹 페이지에서 파일 업로드하는 기능을 추가해주세요"라는 기능 요청을 받곤한다. 그때마다 팀장님께서는 "보안적으로 아주 문제가 많이 발생할 수 있습니다."하면서 기본적으로 부정적인 입장을 내비치시곤 하셨다. 그래서 궁금해졌다.

 

 

"파일 업로드 기능을 구현하는 것이 왜 보안적인 관점에서 좋지 않은가?"

 

 

처음에는 감이 안와서 구글에 당장 "파일 업로드 개발" "톰캣 파일 업로드" "nodejs 파일 업로드"를 검색했다. 개발 당시에 문제가 있는 건지...해서. 근데 다들 개발자스러운 내용들만 있고 내가 원하는 보안적인 관점에 대해서 기술한 게 없었다. 그래서 팀장님께 여쭤보았고 아래와 같이 정리했다.

 

"파일 업로드 기능을 구현하므로써 감사에서 보안 취약점에 걸리는 사항들이 많다."

 

즉, 기능 자체는 당연히 개발이 가능한 것이고 필요하다면 개발해야하는 것이다. 그러나 파일 업로드 기능을 사용하게 된다면 제품 보안 감사시에 추가로 대응해야하는 내용들이 늘어난다. 예를 들어 확장자를 달리해서 확인해야한다거나 각종 보안 공격에서 수행할 수 있는 내용들을 확인해봐야한다. 

 

생각해보면 인터넷보안 수업에서 OWASP top 10 에 대해서 들었던 적이 있다. 이 내용 실습하기 위해 야매로 게시판 만들어서 10가지 공격 시도해보았다. 근데 거기서 파일 업로드 관련 내용은 없었던 거 같다. 하지만 OWASP 에서 연관된 내용이 있을 것 같다는 생각이 들어서 당장 OWASP top 10 2020을 찾아보았다. 내가 배웠을떄는 2016인가 그랬는데 벌써 2020이라니..

 

sucuri.net/guides/owasp-top-10-security-vulnerabilities-2020/

 

OWASP Top 10 Security Vulnerabilities 2020 | Sucuri

Learn about the 2020 OWASP Top 10 vulnerabilities for website security. Visit our guide to see examples and read how to protect your site from security risks.

sucuri.net

 

해당 페이지에서 'upload'로 검색하였을때 내가 생각한 연관 있는 내용이다.

 

What are the risks of sensitive data exposure?

According to the OWASP Top 10, here are a few examples of what can happen when sensitive data is exposed:

  • Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text.
  • Scenario #2: A site doesn’t use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user’s session cookie. The attacker then replays this cookie and hijacks the user’s (authenticated) session, accessing or modifying the user’s private data. Instead of the above they could alter all transported data, e.g. the recipient of a money transfer.
  • Scenario #3: The password database uses unsalted or simple hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.

 

What are the XML external entity attack vectors?

According to the OWASP Top 10, the XML external entities (XXE) main attack vectors include the exploitation of:

  • Vulnerable XML processors if malicious actors can upload XML or include hostile content in an XML document
  • Vulnerable code
  • Vulnerable dependencies
  • Vulnerable integrations

 

How to prevent XML external entity attacks

Some of the ways to prevent XML External Entity attacks, according to OWASP, are:

  • Whenever possible, use less complex data formats ,such as JSON, and avoid serialization of sensitive data.
  • Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system.
  • Use dependency checkers (update SOAP to SOAP 1.2 or higher).
  • Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet ‘XXE Prevention.’
  • Implement positive (“whitelisting”) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes.
  • Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar.
  • SAST tools can help detect XXE in source code – although manual code review is the best alternative in large, complex applications with many integrations.

 

 

이런 것들을 종합하여봤을때, 파일 업로드 기능이 잘못된게 아니라 파일 업로드 기능을 통해 악성코드가 포함된 파일이나 서버에서 실행시킬 수 있는 쉘 파일 등이 올라가게 되면 문제가 되는 것이다. 그 문제들이 민감 정보 노출이라던가 xml 을 이용하여 서버 설정 변경이 가능하다. 

 

그렇다면 어떻게 막을 수 있을까?

 

민감 정보 노출에서 설명한 내용은 아니고 xml external entity 공격을 막기 위해 설명된 내용인데 업로드한 파일에 대해서 verify가 필요하다고 말한다. 하지만 업로드하는 모든 파일에 대해서 검증하게 된다면 업로드에 많은 시간이 소요될 뿐더러 올릴 수 있는 모든 파일의 확장자에 대해서 검증이 거의 불가능하다. 따라서 애초에 "파일 업로드"기능을 막는 것이다.

 

이렇게 "왜 파일 업로드 기능이 보안적인 관점에서 좋지 않은가?"에 대한 해답을 찾아보았다. 웹은 참 취약한 것들이 많은 것 같다. 글쎄 웹이 취약하기보다는 웹을 하는 사람이 많아서 이런 취약점도 많이 알게된 것일수도 있겠다는 생각이 든다. 무궁무진한 세계이다. 참~