데이터베이스 쿼리는 인젝션 공격에 취약하지 않아야 합니다.
URL 매개변수와 같이 사용자가 제공한 데이터는 항상 신뢰할 수 없고 오염된 것으로 간주해야 합니다.
공격자는 오염된 데이터에서 직접 SQL 쿼리를 생성하면 쿼리 자체의 초기 의미를 변경하는 특수하게 조작된 값을 삽입할 수 있습니다.
데이터베이스 쿼리 인젝션 공격이 성공하면 데이터베이스에서 중요한 정보를 읽거나 수정 또는 삭제할 수 있으며, 심지어 데이터베이스를 종료하거나 임의의 운영 체제 명령을 실행할 수도 있습니다.
일반적으로 해결책은 prepared statements를 사용하고 params와 같은 전용 메서드를 사용하여 변수를 SQL 쿼리 매개변수에 바인딩하여 사용자가 제공한 데이터가 올바르게 이스케이...
HTTP 요청 리디렉션은 위조 공격에 노출되어서는 안됩니다.
URL 매개변수, POST 데이터 페이로드 또는 쿠키와 같은 사용자 제공 데이터는 항상 신뢰할 수 없고 오염된 것으로 간주되어야 합니다.
오염된 데이터를 기반으로 HTTP 리디렉션을 수행하는 애플리케이션은 공격자가 사용자를 악성 사이트로 리디렉션하여 로그인 자격 증명을 탈취하는 등의 작업을 수행할 수 있습니다.
이 문제는 다음와 같은 방법으로 완화될 수 있습니다.
허용 목록에 따라 사용자가 제공한 데이터의 유효성을 검사하고 일치하지 않는 입력은 거부합니다.
사용자 제공 데이터를 기반으로 리디렉션을 수행하지 않도록 애플리케이션을 재설계합니다.
규칙을 어긴 코드
lxml module:
XML 구...
varargs 파라미터를 위해 배열이 만들어져선 안됩니다
varargs(...) 인수로 전달하기만을 위해 배열을 만드는 것은 아무런 의미가 없습니다.
varargs는 배열입니다.
원소들을 그냥 직접 전달하기만 하면 됩니다.
그러면 자동으로 배열로 통합되어 전달됩니다.
varargs(...)가 Object ...인 경우 배열을 전달하는 것 자체가 의도가 불명확할 수 있습니다
배열을 객체 하나로 전달하고 싶었던 건가요? 아니면 객체의 집합을 전달하고 싶었던 건가요?
규칙을 어긴 코드
public void callTheThing() {
//...
doTheThing(new String[] { "s1", "s2"}); // 규칙을 어긴 코드: 필요없음
doThe...
Jump 구문은 중복되어선 안됩니다
return continue 같은 Jump 구문은 프로그램 실행의 기본 흐름을 변경할 수 있습니다.
하지만 가만히 냅둬도 원래 방향으로 유도되는 점프 문이 존재하는 것은 여러분의 키 입력 낭비일 뿐입니다.
규칙을 어긴 코드
public void foo() {
while (condition1) {
if (condition2) {
continue; // 규칙을 어긴 코드
} else {
doTheThing();
}
}
return; // 규칙을 어긴 코드; 이 메소드는 void 메소드입니다
}
규칙을 준수한 해결책
public void foo() {
w...
클래스는 너무 많은 "static" 구문을 가져와서는(imports) 안됩니다.
클래스를 static 으로 가져오는 것은 그 클래스의 public static 멤버들을 클래스 이름 없이 사용할 수 있게 합니다.
이것은 편리하지만, 너무 많은 클래스들을 static 하게 가져오는 경우 코드가 온란스럽고 유지보수하기 어려울 수 있습니다.
규칙을 어긴 코드
기본 임계값인 4에서:
import static java.lang.Math.*;
import static java.util.Collections.*;
import static com.myco.corporate.Constants.*;
import static com.myco.division.Constants.*;
import static co...
내부 클래스(inner class) 는 너무 많은 코드 라인을 가져서는 안됩니다.
내부 클래스는 전체 파일의 복잡도를 관리하기 위해 짧고 간단해야합니다.
특정 임계값을 넘어선 내부 클래스는 자체 파일로 외부화되어야 합니다.
If you like SONARKUBE, don’t forget to give me a star. 
원문으로 바로가기
원문으로 바로가기파일들은 오직 하나의 최상위 클래스 혹은 인터페이스에만 포함되어야 합니다.
너무 커지는 파일은 많은 책임을 포함하려는 경향이 있으며, 이는 필연적으로 이해하거나 유지보수하기 어려워지게 됩니다.
이 파일들이 여러 최상위 클래스와 인터페이스를 가지는 경우 이해하거나 유지보수하기 두 배는 더 어렵습니다.
파일을 파일 당 하나의 최상위 클래스 또는 인터페이스에만 포함되도록 나누는 것이 좋습니다.
If you like SONARKUBE, don’t forget to give me a star.
원문으로 바로가기
원문으로 바로가기클래스는 너무 많은 필드를 포함해서는 안됩니다.
너무 커지는 클래스는 많은 책임을 포함하려는 경향이 있고, 그로 인해 이해하거나 유지보수하기 어려워집니다. 클래스에 필드가 너무 많다는 것은 클래스가 너무 커졌다는 것을 의미합니다.
특정 임계값 이상에서는 클래스를 더 잘 정의된 주제에 초점을 맞춘 작은 클래스들로 리팩토링하는 것이 좋습니다.
If you like SONARKUBE, don’t forget to give me a star.
원문으로 바로가기
원문으로 바로가기전체 글 239개, 30 페이지