2017-05-04 1 views
1

나는 이것이 광범위한 질문이라는 것을 알고 있지만, 나는 여기서 뭔가를 놓치고 있다고 생각한다. 공격자가 inspect 요소를 사용하고 javascript 및 html을 편집하여 사이트에 손상을 줄 수 있습니까? 예를 들어 누군가가 입력의 최대 길이를 변경하고 서버를 손상시킬 수있는 많은 양의 데이터를 업로드하는 것은 너무 쉬운 것처럼 보입니다. 서버에서 데이터를 확인하는 것은 항상 좋은 습관이지만 여전히 쉽지 않은 것 같습니다. 또는 잠재적으로 위험한 또 다른 예는 공격자가 $.ajax 호출을 망쳐 서 잘못된 정보를 서버에 보낼 수 있는지 여부입니다. 그것은 내가 걱정해야 할 것이거나 공격자 브라우저에서 일시적으로 변경되는 것입니까?공격자가 inspect 요소를 해로 사용할 수 있습니까?

+0

대답은 예입니다. – wOxxOm

+0

그들은 웹 브라우저를 전혀 사용할 필요가 없습니다. 그들은 귀하의 사이트에서 원하는 지옥 네트워크 요청을 던져 버릴 수 있습니다. 이는 일반적인 사용에서 발생하는 것과는 전혀 다를 수 있습니다. 거의 모든 것으로 보이는 요청을 준비해야합니다. – user2357112

답변

1

변경 사항은 개별 사용자의 브라우저에서 일시적입니다.

그러나 변경 사항으로 인해 해당 사용자는 백엔드와 상호 작용할 수 있지만 그렇게 할 수는 있습니다. 이것은 사이트가 공격받는 한 방법입니다.

표준 규칙은 사용자/브라우저에서 오는 입력을 절대 신뢰하지 않는 것입니다. 숨겨진 필드의 값을 신뢰하지 말고, 길이를 변경하지 않았다고 믿지 말고, 새 값 (예 : 드롭 다운)을 추가하지 않았다고 신뢰하지 말고, 자바 스크립트에서 수행 된 유효성 검사를 신뢰하지 말고, 등

몇 가지 예 : 과거에

  • 일부 쇼핑 사이트는 형태의 숨겨진 필드로 지불 할 수있는 금액을 포함한다. 이 값을 변경하면 거래를 승인하는 동안 신용 카드로 청구 된 금액이 변경되었습니다.
  • SQL 및 HTML/Script 주입 공격까지 열어주는 백엔드 서비스에 직접 게시하여 건너 뛸 수있는 Javascript 유효성 검사 규칙이있는 사이트입니다.
  • 예상치 못한 값을 양식에 추가 할 수있는 드롭 다운, 라디오 버튼 및 확인란 입력을 입력하십시오.
+0

Trevor의 답변에 추가 : 웹 사이트가 실제로 어떻게 공격 당하는지 이해하면 포스터가 도움이됩니다. 거의 모든 해커가 [burp suite] (https://vimeo.com/148320460)를 사용합니다. – TheGreatContini

+0

좋아요,이 모든 대답들이 나를 겁주고 있습니다! 서버 측 유효성 검사에 대해 매우주의해야합니다. 좋은 대답 btw! –

0

이 문제에 대해 걱정해야합니다. 클라이언트의 입력을 신뢰하지 마십시오. 클라이언트 측에서 수행중인 모든 검사가 실제로 실행될 것으로 기대하지 마십시오. 서버 측에서 항상 입력을 확인해야합니다. 이미 언급했듯이 사용자는 다양한 검사 도구를 사용하여 로컬 코드를 변경하거나 악성 패킷을 손으로 완전히 조작 할 수 있습니다.

0

예, 가능합니다. 요소를 검사 할 때 모든 요소를 ​​로컬에서 수정할 수 있으므로 로컬 환경의 임시 수정이되지만 서버에 영향을 줄 수있는 값은 수정할 수 있습니다.

예를 들어 온라인 상점이 있고 '제품 수정'옵션이 있다고 가정 해 보겠습니다. 일단 제품 ID를 저장하면 숨겨진 필드가 생겨 백엔드에서 해당 제품을 업데이트하려고 할 때 해당 ID를 사용하여 업데이트 할 제품을 알 수 있습니다. 공격자는 그 값을 쉽게 변경할 수 있으며, 이제는 다른 제품 (자신이 속하지 않은 제품 포함)을 수정할 수 있습니다.

또 다른 고전적인 예는 사용자가 숫자 값만 제출할 수 있다고 가정하는 숫자 필드 일 수 있습니다. 따라서 백엔드에서 해당 숫자를 검색어에 사용합니다 (예 :

).
"SELECT * FROM Products WHERE Price > " + Price; 

숫자 값이 필요하므로 공격자가 SQL 삽입에 대한 텍스트를 보낼 수있는 방법이 없다고 생각하지만 텍스트 입력의 숫자 입력을 변경하거나, 전송하기 전에 javascript 값을 수정하거나 네트워크 트래픽을 차단하고 거기에서 값을 수정하면됩니다. 이제는 다음과 같이 끝낼 수 있습니다 :

"SELECT * FROM Products WHERE Price > 0; DROP TABLE Products--" 

사용자 입력을 신뢰해서는 안되는 주된 이유입니다. 숫자 값을 기대하십니까? 그런 다음 사용하기 전에 번호인지 확인하십시오. 사용자가 제품을 업데이트하고 있습니까? 업데이트하기 전에 제품이 실제로 그에게 속해 있는지 확인하십시오. 데이터에 대해 maxlength 속성이 있습니까? 서버를 다시 확인하여 길이가 유효한지 확인하십시오.

정말 쉽고 간단한 것처럼 보이지만 사람들은 실수를합니다. 간단한 예제는 "Heart Bleed"버그입니다. 사용자가 제출 한 데이터를 신뢰하는 대신 요청 길이를 확인하여 피해야했던 모든 버그가 있습니다.

이것이 사용자가 제출 한 데이터를 절대 신뢰하지 않아야하고 백엔드에서 항상 이중 체크를 수행해야하는 주된 이유입니다.

관련 문제