모바일 앱 취약점 점검을 하다 보면 이런 구조를 자주 만납니다. iOS 네이티브(Swift)는 껍데기, 실제 기능은 전부 Flutter(Dart)Flutter 쪽은 --obfuscate로 난독화가 되어 있는데, 네이티브 쪽은 아무 조치가 없습니다. 심볼을 떠보면 벤더와 플랫폼 심볼만 나오고요. 개발팀은 "네이티브에는 로직이 없어서 할 게 없다"고 답변합니다. 이걸 양호로 볼 수 있을까요? 아니면 "네이티브 난독화 미적용"으로 지적해야 할까요? 이 글에서는 Flutter 앱의 네이티브 영역에 실제로 무엇이 들어 있는지, 왜 그 부분은 난독화 대상이 아닌지, 그리고 그럼에도 반드시 확인해야 하는 한 가지를 정리했습니다.🎯 상황 정리점검 현장에서 마주치는 전형적인 구성입니다.영역구현 내용난독화 상태Flutt..
전자금융기반시설 취약점 분석·평가를 몇 번 돌려보면 이상하게 걸리는 지점이 하나 있습니다.정보보호시스템은 로그를 백업하는 것으로 끝나지 않고, 원격 서버와 실시간으로 연동하고 있는지까지 봅니다. 그런데 같은 점검표에서 서버로 넘어가면 그런 항목이 없습니다. 로깅이 켜져 있는지, 로그 파일 권한이 적절한지, 정기적으로 검토하는지, 보관 기간을 지키는지까지는 보는데 "어디에 보내고 있는가"는 묻지 않습니다.그래서 두 가지 방향으로 의심이 갑니다.정보보호시스템 쪽 요구가 과한 것인지, 아니면 서버는 백업만 되어 있으면 실시간 원격 관리가 필요 없는 것인지. 결론부터 말하면 둘 다 아닙니다. 이건 요구 수준의 문제가 아니라 점검 기준이 어떤 논리로 설계되었는가의 문제이고, 그 설계에는 명확한 의도와 명확한 공백..
취약점 점검이나 EOS 현황 조사를 하다 보면 이런 답변을 자주 듣습니다."그 서버 ELS 걸려 있어요. 2029년까지 지원됩니다."계약서를 확인해보면 실제로 맞습니다. ELS 구독은 유효하고, 만료일도 2029년입니다. 그런데 서버에 들어가서 rpm -qa --last를 찍어보면 마지막 패치가 몇 년 전입니다. 계약은 살아 있는데 패치는 없는, 이상한 상태입니다.원인은 대부분 하나입니다. 서버가 7.9가 아니기 때문입니다. 이 글에서는 RHEL 7 ELS의 적용 조건이 무엇인지, 왜 7.8에는 패치가 오지 않는지, 그리고 우리 서버가 실제로 패치를 받고 있는지 확인하는 방법을 정리했습니다.🎯 먼저 용어부터 정리합니다현장에서 가장 많이 꼬이는 지점이 용어입니다. 벤더마다 이름이 달라서 대화가 어긋납니다..
- Total
- Today
- Yesterday
- AI보안
- 샤이니헌터스
- 해킹예방
- 전자금융기반시설
- 취약점
- 스마트폰보안
- KISA
- SAP
- 정보보안
- 랜섬웨어
- 공급망공격
- 전자금융기반시설취약점분석평가
- 보안상식
- awssap
- 개인정보보호
- 2단계인증
- AWS
- 악성코드
- cve
- 보안꿀팁
- 개인정보유출
- 보안뉴스
- 사이버보안
- 개발자보안
- 금취분평
- 전자금융취약점분석평가
- 암호화폐보안
- 세븐일레븐해킹
- ASV
- 해킹주의
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
