코드 품질이 낮으면 예측할 수 없는 동작이 발생합니다. 사용자 입장에서는 사용 편의성이 떨어지는 것으로 나타나는 경우가 많습니다. 공격자에게는 예상치 못한 방법으로 시스템에 부담을 줄 수 있는 기회가 됩니다.
<script>
태그가 포함되어 있는지 확인합니다.
...
public String tagProcessor(String tag){
if (tag.toUpperCase().equals("SCRIPT")){
return null;
}
//does not contain SCRIPT tag, keep processing input
...
}
...
Example 1
의 문제는 java.lang.String.toUpperCase()
를 로케일 없이 사용하는 경우 기본 로케일의 규칙이 사용된다는 점입니다. 터키어 로케일 "title".toUpperCase()
를 사용하는 경우 “T\u0130TLE”가 반환되며, 여기서 “\u0130”은 “위에 점이 있는 라틴어 대문자” 문자입니다. 이로 인해 예기치 않은 결과가 발생할 수 있습니다. 예를 들어 Example 1
에서는 이 코드를 사용하면 “script” 단어가 이 검증에서 catch되지 않아 Cross-Site Scripting 취약점이 발생할 수 있습니다.
...
import java.sql.PreparedStatement;
import com.sap.sql.NativeSQLAccess;
String mssOnlyStmt = "...";
// variant 1
PreparedStatement ps =
NativeSQLAccess.prepareNativeStatement(
conn, mssOnlyStmt);
. . .
// variant 2
Statement stmt =
NativeSQLAccess.createNativeStatement(conn);
int result = stmt.execute(mssOnlyStmt);
. . .
// variant 3
CallableStatement cs =
NativeSQLAccess.prepareNativeCall(
conn, mssOnlyStmt);
. . .
...
public class Box{
public int area;
public static final int width = 10;
public static final Box box = new Box();
public static final int height = (int) (Math.random() * 100);
public Box(){
area = width * height;
}
...
}
...
Example 1
에서 width
가 10이므로 box.area
는 10의 배수인 임의의 정수라고 예상할 수 있습니다. 그러나 실제로 해당 값은 항상 하드코드된 0 값입니다. 컴파일 시 상수를 사용하여 선언된 정적 final 필드가 먼저 초기화된 다음 각 필드가 순서대로 실행됩니다. 즉, height
는 컴파일 시 상수가 아니므로 box
가 선언된 후에 선언되기 때문에 height
필드가 초기화되기 전에 생성자가 호출됩니다.
...
class Foo{
public static final int f = Bar.b - 1;
...
}
...
class Bar{
public static final int b = Foo.f + 1;
...
}
This example is perhaps easier to identify, but would be dependent on which class is loaded first by the JVM. In this exampleFoo.f
could be either -1 or 0, andBar.b
could be either 0 or 1.
null
인지 검사하기 전에 null
이 될 수 있는 포인터를 역참조할 경우 발생합니다. 검사 후 역참조(dereference-after-check) 오류는 프로그램이 null
인지 여부를 명시적으로 검사하지만, null
인 것으로 알려진 포인터를 역참조할 때 발생합니다. 이 유형의 오류는 철자 오류 또는 프로그래머의 실수로 발생합니다. 저장 후 역참조(dereference-after-store) 오류는 프로그램이 명시적으로 포인터를 null
로 설정하고 이를 나중에 역참조할 경우에 발생합니다. 이 오류는 프로그래머가 선언된 상태의 변수를 null
로 초기화하여 발생하는 경우가 많습니다.foo
가 null
임을 확인한 다음 잘못 역참조합니다. if
문에서 검사할 때 foo
가 null
이면 null
dereference가 발생하여 null 포인터 예외가 일어납니다.예제 2: 다음 코드에서 프로그래머는 변수
if (foo is null) {
foo.SetBar(val);
...
}
foo
가 null
이 아닌 것으로 가정한 다음 개체를 역참조하여 이 가정을 확인합니다. 그러나 프로그래머는 나중에 foo
를 null
에 대해 검사함으로써 가정을 반박합니다. if
문에서 검사할 때 foo
가 null
이 되면 역참조될 때도 null
이 되어 null 포인터 예외가 발생할 수 있습니다. 역참조가 안전하지 않거나 이후의 검사가 필요하지 않게 됩니다.예제 3: 다음 코드에서 프로그래머는 명시적으로 변수
foo.SetBar(val);
...
if (foo is not null) {
...
}
foo
를 null
로 설정합니다. 나중에 프로그래머는 개체의 null
값을 검사하기 전에 foo
를 역참조합니다.
Foo foo = null;
...
foo.SetBar(val);
...
}
null
인지 검사하기 전에 null
이 될 수 있는 포인터를 역참조할 경우 발생합니다. 검사 후 역참조(dereference-after-check) 오류는 프로그램이 null
인지 여부를 명시적으로 검사하지만, null
인 것으로 알려진 포인터를 역참조할 때 발생합니다. 이 유형의 오류는 철자 오류 또는 프로그래머의 실수로 발생합니다. 저장 후 역참조(dereference-after-store) 오류는 프로그램이 명시적으로 포인터를 null
로 설정하고 이를 나중에 역참조할 경우에 발생합니다. 이 오류는 프로그래머가 선언된 상태의 변수를 null
로 초기화하여 발생하는 경우가 많습니다.ptr
이 NULL
이 아닌 것으로 가정합니다. 이 가정은 프로그래머가 포인터를 역참조하면 명시적인 것이 됩니다. 프로그래머가 NULL
에 대해 ptr
을 검사하면 이 가정이 반박됩니다. if
문에서 검사할 때 ptr
이 NULL
이 되면 역참조될 때도 NULL
이 되어 조각화 오류가 발생할 수 있습니다.예제 2: 다음 코드에서 프로그래머는 변수
ptr->field = val;
...
if (ptr != NULL) {
...
}
ptr
이 NULL
임을 확인한 다음 실수로 역참조합니다. if
문에서 검사할 때 ptr
이 NULL
이면 null
dereference가 발생하여 조각화 오류가 일어납니다.예제 3: 다음 코드에서 프로그래머는
if (ptr == null) {
ptr->field = val;
...
}
'\0'
문자열이 실제로 0 또는 NULL
인 것을 잊고 null 포인터를 역참조하여 조각화 오류가 일어납니다.예제 4: 다음 코드에서 프로그래머는 명시적으로 변수
if (ptr == '\0') {
*ptr = val;
...
}
ptr
를 NULL
로 설정합니다. 나중에 프로그래머는 개체의 null
값을 검사하기 전에 ptr
를 역참조합니다.
*ptr = NULL;
...
ptr->field = val;
...
}
null
인지 여부를 명시적으로 검사하지만, null
인 것으로 알려진 개체를 역참조할 때 발생합니다. 이 유형의 오류는 철자 오류 또는 프로그래머의 실수로 발생합니다.foo
이 null
임을 확인한 다음 실수로 역참조합니다. if
문에서 검사할 때 foo
가 null
이면 null
dereference가 발생하여 null 포인터 예외가 일어납니다.
if (foo == null) {
foo.setBar(val);
...
}
require
호출을 우회할 수 있습니다.
function withdrawWinnings() {
require(uint32(msg.sender) == 0);
_sendWinnings();
}
function _sendWinnings() {
msg.sender.transfer(this.balance);
}
assert
를 사용하여 Lock
계약 인스턴스의 잔액이 특정 값(msg.value
)임을 확인합니다.
contract Lock {
constructor (address owner, uint256 unlockTime) public payable {
...
}
}
contract Lockdrop {
...
function lock(...) {
uint256 eth = msg.value;
address owner = msg.sender;
uint256 unlockTime = unlockTimeForTerm(term);
Lock lockAddr = (new Lock).value(eth)(owner, unlockTime);
assert(address(lockAddr).balance == msg.value);
}
}
transfer()
및 send()
와 같은 값 전송에 사용되는 트랜잭션에 영향을 줄 수도 있습니다.
interface ICallable {
function callMe() external;
}
contract HardcodedNotGood {
function callWithArgs() public {
callable.callMe{gas: 10000}();
}
}