어떤 일반적인 웹 공격에 대해 알아야 합니까?[닫은]
https://stackoverflow.com/questions/23102
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
나는 웹 프로그래밍에 관해서는 여전히 매우 미숙하며 클라이언트 애플리케이션에 대부분의 시간을 보냈습니다.그래서 내 사이트에서 두려워하거나 테스트해야 하는 일반적인 공격이 무엇인지 궁금합니다.
다른 팁
나는 게시하고있다 OWASP 상위 2007 축약 목록 여기에서는 소스가 다운될 경우를 대비해 사람들이 다른 링크를 찾아볼 필요가 없습니다.
크로스 사이트 스크립팅(XSS)
- XSS 결함은 애플리케이션이 사용자가 제공한 데이터를 가져와 해당 콘텐츠를 먼저 확인하거나 인코딩하지 않고 웹 브라우저로 보낼 때마다 발생합니다.XSS를 사용하면 공격자가 피해자의 브라우저에서 스크립트를 실행하여 사용자 세션을 가로채고, 웹 사이트를 훼손하고, 웜을 유입시킬 수 있습니다.
주입 결함
- 주입 결함, 특히 SQL 주입은 웹 애플리케이션에서 흔히 발생합니다.주입은 사용자가 제공한 데이터가 명령이나 쿼리의 일부로 인터프리터에 전송될 때 발생합니다.공격자의 악의적인 데이터는 인터프리터를 속여 의도하지 않은 명령을 실행하거나 데이터를 변경하도록 합니다.
악성 파일 실행
- RFI(원격 파일 포함)에 취약한 코드를 사용하면 공격자가 적대적인 코드와 데이터를 포함할 수 있어 서버 전체가 손상되는 등 파괴적인 공격이 발생합니다.악의적인 파일 실행 공격은 PHP, XML 및 사용자의 파일 이름이나 파일을 허용하는 모든 프레임워크에 영향을 미칩니다.
안전하지 않은 직접 객체 참조
- 직접 개체 참조는 개발자가 파일, 디렉터리, 데이터베이스 레코드 또는 키와 같은 내부 구현 개체에 대한 참조를 URL 또는 양식 매개 변수로 노출할 때 발생합니다.공격자는 이러한 참조를 조작하여 인증 없이 다른 개체에 액세스할 수 있습니다.
크로스 사이트 요청 위조(CSRF)
- CSRF 공격은 로그온한 피해자의 브라우저가 취약한 웹 애플리케이션에 사전 인증된 요청을 보내도록 강제하고, 그러면 피해자의 브라우저가 공격자에게 이익이 되는 적대적인 작업을 수행하도록 강제합니다.CSRF는 공격하는 웹 애플리케이션만큼 강력할 수 있습니다.
정보 유출 및 부적절한 오류 처리
- 애플리케이션은 의도치 않게 구성, 내부 작업에 대한 정보를 유출하거나 다양한 애플리케이션 문제를 통해 개인정보를 침해할 수 있습니다.공격자는 이 약점을 이용하여 민감한 데이터를 훔치거나 더 심각한 공격을 수행합니다.
손상된 인증 및 세션 관리
- 계정 자격 증명과 세션 토큰이 제대로 보호되지 않는 경우가 많습니다.공격자는 다른 사용자의 신원을 가장하기 위해 비밀번호, 키 또는 인증 토큰을 손상시킵니다.
안전하지 않은 암호화 저장소
- 웹 애플리케이션은 데이터와 자격 증명을 보호하기 위해 암호화 기능을 제대로 사용하는 경우가 거의 없습니다.공격자는 신원 도용 및 신용카드 사기 등의 기타 범죄를 저지르기 위해 취약하게 보호되는 데이터를 사용합니다.
안전하지 않은 통신
- 애플리케이션은 민감한 통신을 보호해야 할 때 네트워크 트래픽을 암호화하지 못하는 경우가 많습니다.
URL 액세스 제한 실패
- 종종 애플리케이션은 승인되지 않은 사용자에게 링크나 URL이 표시되는 것을 방지하여 중요한 기능만 보호합니다.공격자는 이 약점을 이용하여 해당 URL에 직접 액세스하여 무단 작업에 액세스하고 수행할 수 있습니다.
-아담
이 세 가지가 가장 중요합니다.
모두가 "SQL 주입"이라고 말할 것입니다. 왜냐하면 이 취약점은 가장 무섭게 들리는 취약점이자 가장 이해하기 쉬운 취약점이기 때문입니다.XSS(Cross-Site Scripting)는 이해하기 쉽기 때문에 2위를 차지할 것입니다."잘못된 입력 유효성 검사"는 취약점이 아니라 보안 모범 사례에 대한 평가입니다.
이것을 다른 관점에서 시도해 보겠습니다.다음은 웹 애플리케이션에서 구현될 때 문제를 일으킬 수 있는 기능입니다.
동적 SQL(예: UI 쿼리 빌더)이제 웹앱에서 SQL을 안정적으로 안전하게 사용하는 유일한 방법은 쿼리의 각 매개 변수를 변수에 명시적으로 바인딩하는 매개 변수화된 쿼리를 사용하는 것임을 알고 계실 것입니다.웹 앱에서 이 규칙을 가장 자주 위반하는 경우는 악의적인 입력이 이름과 같은 명확한 매개변수가 아니라 쿼리 속성인 경우입니다.확실한 예는 검색 사이트에서 볼 수 있는 iTunes와 같은 "스마트 재생 목록" 쿼리 빌더로, where 절 연산자와 같은 항목이 백엔드로 직접 전달됩니다.뒤집어 보아야 할 또 다른 큰 바위는 테이블 열 정렬입니다. 여기서 HTTP 매개변수에 DESC가 노출되는 것을 볼 수 있습니다.
파일 업로드.파일 업로드는 파일 경로 이름이 의심스럽게 URL 경로 이름과 유사해 보이고 웹 서버에서 파일 시스템의 디렉터리에 URL을 지정하는 것만으로도 "다운로드" 부분을 쉽게 구현할 수 있기 때문에 사람들을 혼란스럽게 합니다.우리가 테스트한 업로드 핸들러 10개 중 7개는 공격자가 서버에 있는 임의의 파일에 액세스할 수 있도록 허용합니다. 왜냐하면 앱 개발자는 쿼리에 적용되는 것과 동일한 권한이 파일 시스템 "open()" 호출에 적용된다고 가정했기 때문입니다.
비밀번호 저장.내가 암호를 잃어버렸을 때 응용 프로그램이 원시 암호를 나에게 우편으로 돌려줄 수 있다면 실패한 것입니다.비밀번호 저장에 대한 안전하고 신뢰할 수 있는 유일한 대답은 bcrypt입니다.PHP를 사용하고 있다면 아마도 PHPpass가 필요할 것입니다.
난수 생성.웹 앱에 대한 전형적인 공격:다른 사용자의 비밀번호를 재설정하고, 앱이 암호화가 강력하지 않은 시스템의 "rand()" 기능을 사용하기 때문에 비밀번호를 예측할 수 있습니다.이는 암호화를 수행하는 모든 곳에 적용됩니다.그런데 다음과 같은 행동을 해서는 안 됩니다.어디에서나 암호화폐에 의존하고 있다면 취약할 가능성이 매우 높습니다.
동적 출력.사람들은 입력 유효성 검사를 너무 많이 믿습니다.특히 메타문자가 사용자 입력의 필수 부분인 실제 세계에서는 가능한 모든 메타 문자의 사용자 입력을 제거할 가능성이 낮습니다.훨씬 더 나은 접근 방식은 데이터베이스 출력을 필터링하고 이를 quot, gt 및 lt와 같은 HTML 엔터티로 변환하는 일관된 방식을 갖는 것입니다.Rails가 자동으로 이 작업을 수행합니다.
이메일.많은 응용 프로그램은 공격자가 익명 계정을 만들거나 계정을 전혀 사용하지 않고 공격자가 제어하는 전자 메일을 임의의 전자 메일 주소로 보낼 수 있도록 하는 일종의 아웃바운드 메일 기능을 구현합니다.
이러한 기능 외에도 애플리케이션에서 저지를 수 있는 첫 번째 실수는 데이터베이스 행 ID를 어딘가에 노출하여 사용자 X가 단순히 숫자를 "5"에서 "6"으로 변경하여 사용자 Y의 데이터를 볼 수 있도록 하는 것입니다.
bool UserCredentialsOK(User user)
{
if (user.Name == "modesty")
return false;
else
// perform other checks
}
SQL 주입 공격.피하기는 쉽지만 너무 흔합니다.
절대 절대("절대"라고 언급했습니까?) 양식 요소에서 전달된 사용자 정보를 신뢰하지 마십시오.데이터가 애플리케이션의 다른 논리적 계층으로 전달되기 전에 검사되지 않은 경우 사이트 키를 거리에 있는 낯선 사람에게 줄 수도 있습니다.
어떤 플랫폼을 사용하고 있는지는 언급하지 않지만 ASP.NET을 사용한다면 Scott Guthrie와 그의 기사 "를 참조하여 시작하세요.팁/트릭:SQL 주입 공격으로부터 보호".
그런 다음 사용자가 데이터베이스에 제출하고 결국 데이터베이스에서 내보내도록 허용할 데이터 유형을 고려해야 합니다.HTML을 삽입한 다음 나중에 표시하도록 허용하면 크로스 사이트 스크립팅 공격(XSS라고도 함)이 발생할 수 있습니다.
이것이 나에게 떠오르는 두 가지이지만 우리 Jeff Atwood는 좋은 기사를 가지고 있습니다. 코딩 호러 책 리뷰와 함께 "소프트웨어 보안의 19가지 대죄".
여기 있는 대부분의 사람들은 SQL 주입과 XSS를 언급했습니다. 거의 정확하지만 속지 마십시오. 웹 개발자로서 걱정해야 할 가장 중요한 것은 XSS 및 SQL 주입이 시작되는 INPUT VALIDATION입니다.
예를 들어, 정수만 허용하는 양식 필드가 있는 경우 클라이언트 측과 서버 측 모두에서 데이터를 삭제하기 위한 무언가를 구현하고 있는지 확인하십시오.
특히 입력 데이터가 SQL 쿼리로 끝날 경우 입력 데이터를 확인하고 다시 확인하세요.나는 이스케이퍼 함수를 구축하고 쿼리에 들어가는 모든 것을 감싸는 것을 제안합니다.예를 들어:
$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";
마찬가지로, 사용자가 입력한 정보를 웹페이지에 표시하려면 <script> 태그나 Javascript 실행으로 이어질 수 있는 기타 항목(예: onLoad= onMouseOver= 등)을 제거했는지 확인하세요.태그의 속성).
가장 일반적인 공격은 아마도 데이터베이스 주입 공격과 크로스 사이트 스크립팅 공격일 것입니다.주로 이것이 가장 달성하기 쉽기 때문입니다(아마도 프로그래머가 가장 게으른 것이기 때문일 것입니다).
이 사이트에서도 당신이 주의해야 할 가장 피해가 큰 것은 애플리케이션에 대한 코드 삽입과 관련되어 있으므로 XSS(Cross Site Scripting) 및 SQL 삽입(@Patrick의 제안)이 가장 큰 관심사임을 알 수 있습니다.기본적으로 애플리케이션에서 사용자가 어떤 코드든 삽입할 수 있도록 허용하는 경우, 확실히 허용하려는 항목(html 링크, 이미지 등)만 허용하도록 규제 및 테스트를 거쳤는지 확인해야 합니다. )이 전달되고 다른 것은 실행되지 않습니다.
SQL 주입.크로스 사이트 스크립팅.
저장 프로시저 및/또는 매개변수화된 쿼리를 사용하면 SQL 주입으로부터 보호하는 데 큰 도움이 됩니다.또한 아니다 웹 앱이 sa 또는 dbo로 데이터베이스에 액세스하도록 하세요. 표준 사용자 계정을 설정하고 권한을 설정하세요.
AS for XSS(교차 사이트 스크립팅) ASP.NET에는 몇 가지 보호 기능이 내장되어 있습니다.가장 좋은 방법은 유효성 검사 컨트롤과 Regex를 사용하여 입력을 필터링하는 것입니다.
저는 전문가는 아니지만 지금까지 배운 바에 따르면 어떤 사용자 데이터(GET, POST, COOKIE)도 신뢰하지 않는 것이 황금률입니다.일반적인 공격 유형과 자신을 보호하는 방법:
- SQL 주입 공격:준비된 쿼리 사용
- 크로스 사이트 스크립팅:먼저 필터링/이스케이프 처리하지 않고 사용자 데이터를 브라우저에 보내지 않습니다.여기에는 원래 사용자로부터 제공된 데이터베이스에 저장된 사용자 데이터도 포함됩니다.
