어떻게 하면 PHP 의 코드 를 더욱 안전하게 할 수 있 습 니까?

개술
공격 자 는 악성 SQL 명령 을 구성 하여 데이터베이스 에 보 냅 니 다.프로그램 이 사용자 가 입력 한 SQL 명령 에 대해 판단 필 터 를 실행 하지 않 으 면 생 성 된 SQL 문 구 는 안전성 검 사 를 피해 백 엔 드 데이터 베 이 스 를 수정 하 는 다른 문 구 를 삽입 하고 시스템 명령 을 실행 하여 시스템 에 해 를 끼 칠 수 있 습 니 다.
예 를 들 어 id 가 1 인 게시 물 을 삭제 하면 sql 은 다음 과 같 습 니 다.

$post_id = $_POST['post_id'];
$sql = "DELETE FROM posts WHERE user_id = 1 AND id = $post_id";
\DB::statement($sql);

만약 누군가가 post 를 제출 하고 있다 면id 를 입력 할 때 1 OR 1 을 입력 하면 다음 과 같이 구 성 됩 니 다.

$sql = "DELETE FROM posts WHERE user_id = 1 AND id = 1 OR 1";

일반적으로 원생 의 SQL 작업 에 자주 나타 나 는데 프레임 워 크 는 일반적으로 이 방면 의 문 제 를 해결 할 수 있다.일반적으로 매개 변수 제어 나 특수 문 자 를 걸 러 서 상술 한 문 제 를 피한다.
월권 구멍
1.수평 월권
수평 월권 은 같은 역할 을 하 는 사용자 로 자신의 개인 데 이 터 를 방문 하고 조작 할 수 있 을 뿐만 아니 라 다른 사람의 개인 데 이 터 를 방문 할 수 있 으 며 근본적으로 데이터 에 기반 한 접근 권한 이다.
사용자 의 수금 방식 을 삭제 하 는 장면 은 다음 과 같 습 니 다.
graph LR
사용자 로그 인-->token
token-->수령 방식 목록
수령 방식 목록 가 져 오기-token->id 로 삭제
수금 방식{id}을 통 해 delete 요청 을 수행 하 는 경로:localhost/api/payments/{id}
만약 사용자 A 의 수금 방식 이{1,2,3}이 있다 면    사용자 B 의 수금 방식 은{4,5}입 니 다.
데이터 제어 가 되 지 않 으 면 A 로그 인 후 A 의 token 을 가지 고 삭 제 된 인터페이스 localhost/api/payments/4 를 실행 하면 B 가 삭 제 됩 니 다.따라서 destory 방법 에 대한 데이터 제어 가 필요 합 니 다.

# 1        
public function destory($id){
    $payment = Payment::find($id);
    if ($payment->user_id != $this->currentUser->id) {
            return ...
    }
    $payment->delete();
}

# 2   id    
public function destory($id){
    Payment::whereUserId($this->currentUser->id)->whereId($id)->delete();
}

# 3       
class User extends Model{
    public function payments()
    {
            return $this->hasMany('App\Payment');
    }
}

class PaymentController extends Controller{
    public function destory($id)
    {
            $this->currentUser->payments()->whereId($id)->delete();
    }
}

세 번 째 방식 으로 데이터 통 제 를 하 는 것 을 추천 합 니 다.그렇지 않 으 면 대상 을 대상 으로 헛 배 웠 습 니 다.수금 방식 의 목록 을 가 져 오 는 데 도 데이터 권한 제어 가 필요 합 니 다.사용자 와 수금 방식 은 한 쌍 이상 의 관련 관계 가 존재 합 니 다.모델 이 연 결 된 후에 사용자 의 수금 방식 목록 을 가 져 오 면 쓸 수 있 습 니 다.

class PaymentController extends Controller{
    public function index($id)
    {
        #      
        $payments = $this->currentUser->payments()->where(function($query){
                ...
        })->get();

        #       
        $payments = $this->currentUser->payments;
    }
}

2.수직 월권
낮은 권한 을 가 진 캐릭터 는 일부 경 로 를 통 해 높 은 권한 을 가 진 능력 을 얻 으 면 월권 방문 이 발생 한다.일반 사용자 게 스 트 가 admin 사용자 의 비밀 번 호 를 수정 할 경우;guest 는 배경 에 직접 들 어가 도 메 인 이름 관리,사용자 관리 등 모든 권한 을 얻 을 수 있 습 니 다.
이 문 제 를 해결 하려 면 권한 직책 을 최소 입자 로 세분 화하 고 RBAC 설계 권한 관리 시스템 을 바탕 으로 해 야 한다.다음 과 같은 관련 모델 로 나 뉜 다.
graph LR 
사용자--다 대 다-->캐릭터
사용자--다 중->권한
역할--다 대 다-->권한
요청 을 실행 할 때마다 사전 미들웨어 에서 이 사용자 가 요청 을 영원히 실행 할 수 있 는 권한 을 판단 하고 권한 이 없 으 면 기각 합 니 다.
3.문맥 월권
공격 자 는 응용 프로그램 상태 기의 빈틈 을 이용 하여 관건 적 인 자원 에 대한 접근 권한 을 얻 을 수 있 기 때문에 상하 문과 관련 된 월권 이 존재 한다.문맥 과 관련 된 월권 구멍 은 일반적으로 업무 논리 적 구멍 에 속한다.비밀 번 호 를 찾 는 과정 에서 공격 자 는 자신의 계 정 정 정 보 를 사용 하여 검증 을 통 해 타인 의 비밀 번 호 를 수정 했다.
graph LR
1.이메일 인증->2.비밀번호 찾기
1 단계 이후 비밀 번 호 를 찾 는 길 을 실행 합 니 다.현재 비밀 번 호 를 찾 은 계 정 이 메 일 박스 검사 후의 계 정 인지 확인 하지 않 으 면 월권 구멍 이 생 길 수 있 습 니 다.
경로:[PUT]localhost/api/users/find-password,매개 변수 이메일 수신,newpassword.
오류:검사 와 수정 은 2 단계 localhost/api/email/check->localhost/api/users/password 로 나 뉜 다.

class UserController extends Controller{
    public function check($data)
    {
        if (checkEmail($data['email'], $data['code'])) {
                return true;
        }
        ...
    }

    public function findPassword()
    {
        $user = User::whereEmail($data['email'])->first();
        $user->password = bcrypt($data['new_password']);
        $user->save();
    }
}

올 바른:find Password 에서 메 일 박스 검 사 를 마 친 계 정 이 현재 비밀 번 호 를 찾 은 계 정 인지 다시 확인 합 니 다.

class UserController extends Controller{

    public function check($data)
    {
        if (checkEmail($data['email'], $data['code'])) {
                return true;
        }
        ...
    }

    public function findPassword($data)
    {
        if (checkEmail($data['email'], $data['code'])) {
                $user = User::whereEmail($data['email'])->first();
                $user->password = $data['new_password'];
                $user->save();
        }
        ...
    }
}

페이지 항목 범 위 를 제한 하여 악의 적 인 요청 을 방지 하 다.
글 목록 의 인터페이스 localhost/api/articles

public function index($params){
    $pageId = $params['pageid'] ?? PAGE_ID;    //  
    $pageSize = $params['pagesize'] ?? 15;  //  

    $articles = Article::where(function ($query) use ($params) {
            ...
    })->take($pageSize)->skip($pageId * $pageSize)->orderby('id', 'desc')->get();
    ...
    ...
}

상기 코드 가 pagesize 의 범 위 를 제한 하지 않 으 면 악성 요청 자 는 pagesize 를 5000,10000 등 심지어 더 큰 수 를 입력 하 라 고 요청 하면 데이터 베이스 에 일정한 압력 을 줄 수 있 습 니 다.localhost/api/articles?pageid=0&pagesize=10000

//          
public function index(){
    $builder = Article::with('category:id,name')->orderBy('id', 'desc')->paginate(8);
    return response()->json(['status' => true, 'count' => $builder->total(), 'articles' => $builder->items()]);
}

JWT 의 Token 은 2 차 암호 화가 필요 합 니 다.
많은 확장 패키지 가 암호 화 된 token 은 안전 하지 않 습 니 다.base 64 로decode 는 암호 화 된 메 인 키,부하 등 중요 한 정 보 를 복호화 할 수 있 기 때문에 보통 JWT 의 token 을 2 차 암호 화 해 야 합 니 다.
파일 업로드 형식 제한
그림 업로드 인터페이스 에 대해 파일 업로드 형식 을 제한 하지 않 으 면 공격 자 는.php 접미사 파일 을 Public/images 디 렉 터 리 에 업로드 한 다음 루트 디 렉 터 리 를 통 해 이 파일 을 실행 할 수 있 습 니 다.
안전 한 파일 업로드 기능 을 설계 하여 상기 문 제 를 피해 야 합 니 다.
1.파일 업로드 디 렉 터 리 를 실행 불가 로 설정
2.파일 형식 판단
3.무 작위 로 파일 이름과 파일 경 로 를 변경 합 니 다.
4.파일 서버 의 도 메 인 이름 을 따로 설정
압축 해제.zip 등 압축 파일 을 자동 으로 쓰 는 코드 를 금지 하거나 피 합 니 다.
단순히 파일 이나 압축 파일 크기 를 제한 하 는 것 은 소 용이 없습니다.ZIP 폭탄 의 zip 파일 은 42KB 에 불과 하지만 압축 을 풀 면 4718592 GB 를 차지 합 니 다.
로그 인 비밀번호 가 폭력 적 으로 풀 리 지 않도록 하 세 요.
1.엄격 한 속도 제한 을 설정 합 니 다.예 를 들 어 로그 인 횟수 제한,로그 인 오류 횟수 가 x 회 에 달 할 때 n 분 동안 로그 인 을 중단 합 니 다.
2.비밀번호 에 무 작위 소금 추가

public function reg(){
    $user = new User;
    $salt = radom(6);
    $user->password = bcrypt($data['password'] . $salt);
    ...
}

생산 환경 에서 정확 하지 않 은 오류 보고 가 민감 한 데 이 터 를 노출 시 키 지 않도록 이상 처 리 를 잘 하 다.
조심 하지 않 으 면 생산 환경 에서 잘못된 오류 보고 로 민감 한 정 보 를 누설 할 수 있 습 니 다.예 를 들 어 폴 더 구조,데이터 베이스 구조,연결 정보 와 사용자 정보 등 입 니 다.
1..env 파일 에서 디 버 깅 모드 닫 기
APP_DEBUG=true
2.php 오류 제어 errorreporting、display_errors

<?php
//       
error_reporting(0);

//    runtime   
error_reporting(E_ERROR | E_WARNING | E_PARSE);

//       
error_reporting(E_ALL);

//    error_reporting(E_ALL);
ini_set("error_reporting", E_ALL);

//    E_NOTICE        
error_reporting(E_ALL & ~E_NOTICE);
?>

display_errors = Off

php 약 한 언어의 디자인 결함:inarray

$array=[0,1,2,'3'];

var_dump(in_array('abc', $array)); //true

var_dump(in_array('1bc', $array)); //true

#            true,   'abc'     0，'1bc'    1

$a = null;
$b = false;
echo $a==$b;  //true

$c = "";
$d = 0;
echo $c==$d   //true

일부 중요 한 곳 에 서 는 데이터 판단 을 위해 사용 해 야 한다.
LFI(로 컬 파일 포함)
LFI(로 컬 파일 포함)는 사용자 가 경험 치 없 이 디스크 에서 파일 을 읽 는 구멍 입 니 다.
필터 사용자 의 입력 을 검증 하지 않 고 렌 더 링 할 템 플 릿 파일 을 GET 요청 으로 불 러 옵 니 다.

<body>
    <?php
      $page = $_GET['page'];
      if(!$page) {
        $page = 'main.php';
      }
      include($page);
    ?></body>

Include 는 PHP 뿐만 아니 라 모든 파일 을 불 러 올 수 있 기 때문에 공격 자 는 시스템 에 있 는 모든 파일 을 대상 으로 전달 할 수 있 습 니 다.
index.php?page=../../etc/passwd
이것 은/etc/passwd 파일 을 읽 고 브 라 우 저 에 보 여 줍 니 다.
이러한 공격 을 방어 하려 면 사용자 가 입력 할 수 있 는 유형 을 자세히 고려 하고 유해 할 수 있 는 문 자 를 삭제 해 야 합 니 다.예 를 들 어 입력 문자 의"..."/"\".
XSS
XSS 는 CSS(Cross Site Script)라 고도 부 르 며 크로스 스 크 립 트 공격 입 니 다.악성 공격 자가 웹 페이지 에 악성 html 코드 를 삽입 하여 사용자 가 이 페이지 를 탐색 할 때 웹 에 삽 입 된 html 코드 가 실행 되 어 악의 적 으로 사용 자 를 공격 하 는 특수 한 목적 을 달성 하 는 것 을 말한다.

<body>
    <?php
        $searchQuery = $_GET['q'];
        /* some search magic here */
    ?><h1>You searched for: <?php echo $searchQuery; ?></h1></body>

사용자 의 내용 을 직접 인쇄 하기 때문에 어떠한 여과 도 거치 지 않 고 불법 사용 자 는 URL:search.php?q=%3Cscript%3Ealert(1)%3B%3C%2Fscript%3E 를 연결 할 수 있 습 니 다.
PHP 가 보 여 주 는 내용 은 다음 과 같 습 니 다.자바 script 코드 가 직접 실 행 됩 니 다.

<body>
<h1>You searched for: <script>alert(1);</script></h1>
<p>We found: Absolutely nothing because this is a demo</p>
</body>

Javascript 가능:

사용자 브 라 우 저 에 있 는 쿠키 를 훔 쳐 갑 니 다

4.567917.브 라 우 저의 기억 암호 기능 을 통 해 사이트 로그 인 계 정과 비밀 번 호 를 얻 을 수 있 습 니 다4.567917.사용자 의 기밀 정 보 를 훔 치기;4.567917.사용자 가 사이트 에서 할 수 있 는 일 은 JS 권한 집행 권한 이 있 으 면 모두 할 수 있 습 니 다.즉,A 사용 자 는 모든 사용자 가 되 는 것 을 모 의 할 수 있 습 니 다

당신 의 홈 페이지 에 악성 코드 를 삽입 합 니 다

htmlenities()를 사용 하여 특수 문 자 를 걸 러 대부분의 xss 공격 을 방지 합 니 다.
CSRF(크로스 오 버 요청 위조)
예 를 들 어 사이트 에 계 정의 링크 를 취소 할 수 있 는 사용자 가 있다.

<a href="http://your-website.com/delete-account" rel="external nofollow" >    </a>

사용자 가 댓 글 을 달 면:

<img src=”http://your-website.com/delete-account”> wow

사용 자 는 이 댓 글 을 볼 때 계 정 을 삭제 합 니 다.
laravel 의 웹 경로 가 기본적으로 csrf 인증 을 열 었 습 니 다.원 리 는 클 라 이언 트 가 무 작위 token 을 만 드 는 것 입 니 다.폼 검사 시 이 token 이 이 페이지 의 요청 인지 판단 하 는 것 입 니 다.
이상 은 어떻게 하면 PHP 의 코드 를 더욱 안전 하 게 할 수 있 는 지 에 대한 상세 한 내용 입 니 다.더 많은 PHP 의 코드 를 더욱 안전 하 게 할 수 있 는 자 료 는 우리 의 다른 관련 글 에 관심 을 가 져 주 십시오!