මේ දිනවල වඩාත් සුලභ ආරක්‍ෂිත හොඳම භාවිතයන්ගෙන් එකක් වන්නේ ඩිරෙක්ටරියක් වොස්ට්ගේ ලේඛන මූලයට වඩා ඉහළින් චලනය වනwp-config.php බවයි. මම ඒ සඳහා කිසි විටෙකත් හොඳ පැහැදිලි කිරීමක් සොයාගෙන නැත, නමුත් මම සිතන්නේ එය වෙබ්රූට් තුළ ඇති අනිෂ්ට හෝ ආසාදිත ස්ක්‍රිප්ට් එකක දත්ත සමුදා මුරපදය කියවීමෙන් ඇති වන අවදානම අවම කිරීමයි.

නමුත්, ඔබට තවමත් වර්ඩ්ප්‍රෙස් වෙත ප්‍රවේශ වීමට ඉඩ දිය යුතුය, එබැවින් open_basedirලේඛන මූලයට ඉහළින් ඇති නාමාවලිය ඇතුළත් කිරීම සඳහා ඔබ පුළුල් කළ යුතුය. එය සමස්ත අරමුණම පරාජය කිරීමක් පමණක් නොව, සේවාදායක ලොග්, උපස්ථ ආදිය ප්‍රහාරකයන්ට නිරාවරණය කළ හැකිද?

නැතහොත් තාක්‍ෂණය උත්සාහ කරන්නේ PHP එන්ජිම විග්‍රහ කිරීම වෙනුවට wp-config.phpඉල්ලන ඕනෑම කෙනෙකුට සරල පා text යක් ලෙස පෙන්වන තත්වයක් වළක්වා ගැනීමට http://example.com/wp-config.phpපමණක්ද? එය ඉතා දුර්ලභ සිදුවීමක් සේ පෙනේ, එය HTTP ඉල්ලීම් වලට ලොග් / උපස්ථ / යනාදිය නිරාවරණය කිරීමේ අවාසිය ඉක්මවා නොයනු ඇත.

සමහර විට වෙනත් ලිපිගොනු නිරාවරණය නොකර සමහර සත්කාරක සැකසුම් තුළ ලේඛන මූලයෙන් පිටත ගෙන යා හැකි නමුත් වෙනත් සැකසුම් වලදී නොවේද?

නිගමනය: මෙම කාරණය සම්බන්ධයෙන් බොහෝ පසුගාමී කරුණු වලින් පසුව, පිළිතුරු දෙකක් මතු වී ඇති අතර, එය බලයලත් ඒවා ලෙස සැලකිය යුතු යැයි මම සිතමි. ආරොන් ඇඩම්ස් wp-config ගෙනයාමට පක්ෂව හොඳ නඩුවක් ඉදිරිපත් කරන අතර chrisguitarguymakes එයට එරෙහිව හොඳ නඩුවක් කරයි . ඔබ නූල් වලට අලුත් නම් සහ සම්පූර්ණ දේ කියවීමට අකමැති නම් ඔබ කියවිය යුතු පිළිතුරු දෙක එයයි. අනෙක් පිළිතුරු අතිරික්ත හෝ සාවද්‍ය ය.

කෙටි පිළිතුර: ඔව්

මෙම ප්‍රශ්නයට පිළිතුර ඔව් සහ වෙනත් ආකාරයකින් පැවසීම වගකීම් විරහිත ය .

දිගු පිළිතුර: සැබෑ ලෝක උදාහරණයක්

wp-config.phpවෙබ් මූලයෙන් පිටත ගමන් කිරීම එහි අන්තර්ගතය ග්‍රහණය කර ගැනීමෙන් වළක්වා ඇති මගේ සැබෑ සේවාදායකයෙන් ඉතා සැබෑ උදාහරණයක් සැපයීමට මට ඉඩ දෙන්න .

දෝෂය:

Plesk හි දෝෂයක් පිළිබඳ මෙම විස්තරය දෙස බලන්න (11.0.9 MU # 27 හි ස්ථාවර කර ඇත):

සත්කාරක සැලැස්ම (117199) සමඟ දායකත්වය සමමුහුර්ත කිරීමෙන් පසුව ප්ලෙස්ක් උප ඩොමේන් ඉදිරියට යැවීම යලි සකසයි.

හානිකර නොවන බවක් පෙනේ, නේද?

හොඳයි, මෙන්න මම මෙම දෝෂය අවුලුවාලීමට කළ දේ:

1. වෙනත් URL වෙත හරවා යැවීම සඳහා උප ඩොමේනයක් සකසන්න (උදා site.staging.server.com. site-staging.ssl.server.com).
2. දායකත්වයේ සේවා සැලැස්ම වෙනස් කරන ලදි (උදා: එහි PHP වින්‍යාසය).

මා මෙය කළ විට, ප්ලෙස්ක් විසින් උප ඩොමේනය පෙරනිමි ලෙස යළි පිහිටුවයි: ~/httpdocs/පරිවර්තකයන් නොමැතිව (උදා: PHP) සක්‍රියව අන්තර්ගතය සේවය කිරීම .

මම දැක්කේ නැහැ. සති ගණන්.

ප්රතිඵලය:

• සමග wp-config.phpවෙබ් මූල දී, ඉල්ලීමක් /wp-config.phpවර්ඩ්ප්රෙස් මානකරන ගොනුව බාගත කර ඇත.
• සමග wp-config.phpවෙබ් මූල පිටත ඉල්ලීමක් /wp-config.phpසම්පූර්ණයෙන්ම හානිකර ගොනු බාගත. සැබෑ wp-config.phpගොනුව බාගත කළ නොහැකි විය.

මේ අනුව, wp-config.phpවෙබ් මූලයෙන් පිටත ගමන් කිරීම සැබෑ ලෝකයේ හොඳ ආරක්‍ෂිත ප්‍රතිලාභ ලබා ගත හැකි බව පැහැදිලිය .

wp-config.phpඔබගේ සේවාදායකයේ ඕනෑම ස්ථානයකට යන්නේ කෙසේද

වර්ඩ්ප්‍රෙස් ඔබේ wp-config.phpගොනුව සඳහා ඔබේ වර්ඩ්ප්‍රෙස් ස්ථාපනයට ඉහළින් එක් ඩිරෙක්ටරියක් ස්වයංක්‍රීයව පෙනෙනු ඇත , එබැවින් ඔබ එය ගෙන ගිය ස්ථානය නම්, ඔබ ඉවරයි!

නමුත් ඔබ එය වෙනත් තැනකට ගෙන ගියහොත් කුමක් කළ යුතුද? පහසු. wp-config.phpපහත කේතය සමඟ වර්ඩ්ප්‍රෙස් නාමාවලියෙහි නව එකක් සාදන්න :

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

(ඉහත සඳහන් මාර්ගය ඔබේ නැවත ස්ථානගත කළ wp-config.phpගොනුවේ සත්‍ය මාර්ගයට වෙනස් කිරීමට වග බලා ගන්න .)

ඔබ යම් ගැටලුවකට මුහුණ දෙන්නේ නම් open_basedir, open_basedirඔබේ PHP වින්‍යාසය තුළ විධානයට නව මාවත එක් කරන්න :

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

ඒක තමයි!

ඊට පටහැනිව තර්ක ඇමතීම

wp-config.phpවෙබ් මූලයෙන් පිටතට යාමට එරෙහි සෑම තර්කයක්ම ව්‍යාජ උපකල්පන මත රැඳී ඇති බව පෙනේ.

තර්කය 1: PHP අක්‍රීය කර ඇත්නම්, ඔවුන් දැනටමත් සිටී

[ wp-config.php] හි අන්තර්ගතය යමෙකු බැලීමට යන එකම ක්‍රමය වන්නේ ඔවුන් ඔබේ සේවාදායකයන් PHP පරිවර්තකය මග හැරියහොත් පමණි… එය සිදුවුවහොත්, ඔබ දැනටමත් කරදරයක වැටී ඇත: ඔවුන්ට ඔබේ සේවාදායකයට access ජු ප්‍රවේශයක් ඇත.

අසත්‍යය : මා ඉහත විස්තර කළ දර්ශනය වැරදි වින්‍යාසයක ප්‍රති result ලයක් මිස ආක්‍රමණයකි.

2 වන තර්කය: අහම්බෙන් PHP අක්‍රීය කිරීම දුර්ලභ වන අතර එබැවින් එය වැදගත් නොවේ

ප්‍රහාරකයාට PHP හසුරුව වෙනස් කිරීමට ප්‍රමාණවත් ප්‍රවේශයක් තිබේ නම්, ඔබ දැනටමත් ඉස්කුරුප්පු කර ඇත. මගේ අත්දැකීම් වලදී අහම්බෙන් සිදුවන වෙනස්කම් ඉතා කලාතුරකිනි, එවැනි අවස්ථාවකදී මුරපදය වෙනස් කිරීම පහසුය.

අසත්‍යය : මා ඉහත විස්තර කළ තත්වය පොදු සේවාදායක වින්‍යාසයකට බලපාන පොදු සේවාදායක මෘදුකාංගයක ඇති දෝෂයක ප්‍රති result ලයකි. මෙය කිසිසේත්ම "දුර්ලභ" නොවේ (ඊට අමතරව, ආරක්ෂාව යනු දුර්ලභ අවස්ථාව ගැන කරදර වීමයි).

ආක්‍රමණයකින් පසු මුරපදය වෙනස් කිරීම කිසිසේත්ම උපකාරී නොවේ. ඇත්ත වශයෙන්ම, වර්ඩ්ප්‍රෙස් භාවිතා කරන්නේ අනියම් බ්ලොග්කරණය සඳහා පමණක් බවත්, ප්‍රහාරකයින් උනන්දු වන්නේ අපවිත්‍ර වීමට පමණක් බවත් අපි තවමත් සිතනවාද? කවුරුහරි ඇතුල් වූ පසු එය යථා තත්වයට පත් කිරීම පමණක් නොව, අපගේ සේවාදායකය ආරක්ෂා කිරීම ගැන කරදර වෙමු.

3 වන තර්කය: ප්‍රවේශය ප්‍රතික්ෂේප කිරීම wp-config.phpප්‍රමාණවත්ය

ඔබගේ අථත්‍ය ධාරක වින්‍යාසය හරහා ඔබට ගොනුවට ප්‍රවේශ වීම සීමා කළ හැකිය .htaccess- නැතහොත් ලේඛන මූලයෙන් පිටත ගමන් කරන ආකාරයටම ගොනුවට බාහිර ප්‍රවේශය effectively ලදායී ලෙස සීමා කිරීම.

අසත්‍යය : අතථ්‍ය ධාරකය සඳහා ඔබේ සේවාදායකයේ පෙරනිමි ඒවා යැයි සිතන්න: PHP නැත .htaccess, නැත , allow from all(නිෂ්පාදන පරිසරයක අසාමාන්‍ය දෙයක් නොවේ). දෛනික මෙහෙයුමකදී ඔබගේ වින්‍යාසය කෙසේ හෝ යළි පිහිටුවනු ලැබුවහොත් - පැනල් යාවත්කාලීන කිරීමක් වැනි - සියල්ල එහි පෙරනිමි තත්වයට නැවත පැමිණෙනු ඇත, එවිට ඔබ නිරාවරණය වේ.

සැකසුම් අහම්බෙන් පෙරනිමි වෙත යළි පිහිටුවන විට ඔබගේ ආරක්ෂක ආකෘතිය අසමත් වුවහොත්, ඔබට වැඩි ආරක්ෂාවක් අවශ්‍ය වේ.

ආරක්ෂිත ස්ථර කිහිපයක් කිසිවෙකු විශේෂයෙන් නිර්දේශ කරන්නේ ඇයි? මිල අධික මෝටර් රථවල අගුල් නොමැත; ඔවුන්ට අනතුරු ඇඟවීම්, ප්‍රතිශක්තිකාරක සහ ජීපීඑස් ට්රැකර් ද ඇත. යමක් ආරක්ෂා කිරීමට වටිනවා නම්, එය නිවැරදිව කරන්න.

තර්කය 4: අනවසරයෙන් ප්‍රවේශ වීම wp-config.phpලොකු දෙයක් නොවේ

[ wp-config.php] හි ඇති එකම සංවේදී දේ දත්ත සමුදා තොරතුරු වේ .

අසත්‍යය : සොරකම් කිරීමේ විභවයන් ගණනාවකදී සත්‍යාපන යතුරු සහ ලවණ භාවිතා කළ හැකිය.

දත්ත සමුදා අක්තපත්‍ර එකම දෙය වුවද wp-config.php, ප්‍රහාරකයෙකු ඔවුන් අතට පත්වීම ගැන ඔබ බිය විය යුතුය .

තර්කය 5: wp-config.phpවෙබ් මූලයෙන් පිටත ගමන් කිරීම ඇත්ත වශයෙන්ම සේවාදායකය අඩු ආරක්ෂිත කරයි

ඔබට තවමත් වර්ඩ්ප්‍රෙස් ප්‍රවේශ වීමට ඉඩ දිය යුතුය [ wp-config.php], එබැවින් open_basedirලේඛන මූලයට ඉහළින් ඇති නාමාවලිය ඇතුළත් කිරීම සඳහා ඔබ පුළුල් කළ යුතුය.

අසත්‍යය : උපකල්පනය wp-config.phpකර ඇත httpdocs/, එය වෙත ගෙනයන්න ../phpdocs/, සහ open_basedirඇතුළත් කිරීමට පමණක් සකසන්න httpdocs/සහ phpdocs/. උදාහරණයක් වශයෙන්:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

( ඔබට එකක් තිබේ නම් සැමවිටම ඇතුළත් /tmp/කිරීමට හෝ ඔබේ පරිශීලක tmp/නාමාවලිය මතක තබා ගන්න .)

නිගමනය: මානකරන ගොනු හැම විටම සෑම විටම කළ යුතු සෑම විටම වෙබ් මූල පිටත පිහිටා

ඔබ ආරක්ෂාව ගැන සැලකිලිමත් නම්, ඔබ wp-config.phpඔබේ වෙබ් මූලයෙන් පිටතට යා යුතුය .

ලොකුම දෙය නම් wp-config.phpසමහර සංවේදී තොරතුරු අඩංගු වේ: ඔබේ දත්ත සමුදා පරිශීලක නාමය / මුරපදය යනාදිය.

එබැවින් අදහස: ලේඛන මූලයෙන් පිටත එය ගෙනයන්න, ඔබ කිසිවක් ගැන කරදර විය යුතු නැත. ප්‍රහාරකයෙකුට කිසි විටෙකත් බාහිර ගොනුවකින් එම ගොනුවට ප්‍රවේශ විය නොහැක.

කෙසේවෙතත්, මෙන්න රබර්: wp-config.phpකිසි විටෙකත් තිරය වෙත කිසිවක් මුද්‍රණය නොකරයි. එය අර්ථ දක්වන්නේ ඔබේ WP ස්ථාපනය පුරාම භාවිතා වන විවිධ නියතයන් පමණි. මේ අනුව යමෙකු එම ගොනුවේ අන්තර්ගතය බැලීමට යන එකම ක්‍රමය වන්නේ ඔවුන් ඔබේ සේවාදායක PHP පරිවර්තකය මග හැරියහොත් පමණි - ඒවා .phpසරල පෙළක් ලෙස ඉදිරිපත් කිරීමට ගොනුව ලබා ගනී. එය සිදුවුවහොත්, ඔබ දැනටමත් කරදරයට පත්ව ඇත: ඔවුන්ට ඔබේ සේවාදායකයට access ජු ප්‍රවේශයක් ඇත (සහ බොහෝ විට root අවසර) සහ ඔවුන්ට කැමති ඕනෑම දෙයක් කළ හැකිය.

මම ඉදිරියට ගොස් ආරක්ෂක දෘෂ්ටිකෝණයකින් ලේඛන මූලයෙන් පිටත ගමන් කිරීමෙන් කිසිදු ප්‍රයෝජනයක් නැතැයිwp-config කියමි - ඉහත හේතු සහ මේවා සඳහා:

1. ඔබගේ අථත්‍ය ධාරක වින්‍යාසය හෝ .htaccess හරහා ඔබට ගොනුවට ප්‍රවේශ වීම සීමා කළ හැකිය - ලේඛනයේ මූලයෙන් පිටත ගමන් කරන ආකාරයටම ගොනුවට බාහිර ප්‍රවේශය effectively ලදායී ලෙස සීමා කිරීම.
2. wp-configSSH හරහා ඔබේ සේවාදායකයට (සීමිත) ප්‍රවේශයක් ලැබුණද, ප්‍රමාණවත් වරප්‍රසාද නොමැති ඕනෑම පරිශීලකයෙකුට ගොනුව කියවීම වැළැක්වීමට ගොනු අවසරයන් දැඩි බව ඔබට සහතික කළ හැකිය .
3. ඔබගේ සංවේදී තොරතුරු, දත්ත සමුදා සැකසුම් භාවිතා කරනුයේ තනි වෙබ් අඩවියක පමණි. එබැවින් ප්‍රහාරකයෙකු එම තොරතුරු වෙත ප්‍රවේශය ලබා ගත්තද, එය බලපාන එකම වෙබ් අඩවිය වන්නේ wp-config.phpගොනුව අයත් වර්ඩ්ප්‍රෙස් ස්ථාපනයයි. වැදගත්ම දෙය නම්, එම දත්ත සමුදා පරිශීලකයාට එම WP ස්ථාපනය දත්ත ගබඩාවට කියවීමට හා ලිවීමට අවසර ඇති අතර වෙන කිසිවක් නැත - වෙනත් පරිශීලකයින්ට අවසර ලබා දීමට ප්‍රවේශයක් නොමැත. වෙනත් වචන වලින් කිවහොත්, ප්‍රහාරකයෙකු ඔබගේ දත්ත ගබඩාවට ප්‍රවේශය ලබා ගන්නේ නම්, එය හුදෙක් උපස්ථයකින් ප්‍රතිස්ථාපනය කිරීම (4 වන කරුණ බලන්න) සහ දත්ත සමුදා පරිශීලකයා වෙනස් කිරීම ය.
4. ඔබ බොහෝ විට උපස්ථ කරයි. බොහෝ විට සාපේක්ෂ යෙදුමක් වීම: ඔබ දිනපතා ලිපි 20 ක් පළ කරන්නේ නම්, ඔබ සෑම දිනකම හෝ සෑම දින කිහිපයකදීම උපස්ථ කිරීම වඩා හොඳය. ඔබ සතියකට වරක් පළ කරන්නේ නම්, සතියකට වරක් උපස්ථ කිරීම ප්‍රමාණවත් වේ.
5. ඔබට ඔබේ වෙබ් අඩවිය අනුවාද පාලනය යටතේ ඇත ( මේ වගේ ), එයින් අදහස් කරන්නේ ප්‍රහාරකයෙකුට ප්‍රවේශය ලැබුණත්, ඔබට පහසුවෙන් කේත වෙනස්වීම් හඳුනාගෙන ඒවා පෙරළා දැමිය හැකිය. ප්‍රහාරකයෙකුට ප්‍රවේශය තිබේ නම් wp-config, ඔවුන් වෙනත් දෙයක් සමඟ පටලවා ගෙන ඇත.
6. දත්ත සමුදා තොරතුරු ඇත්ත වශයෙන්ම ඇති එකම සංවේදී දේ වන අතර wp-config, ඔබ ඒ ගැන සැලකිලිමත් වන නිසා (3 සහ 4 ලක්ෂ්‍යය බලන්න), එය විශාල ගනුදෙනුවක් නොවේ. ලවණ සහ එවැනි ඕනෑම වේලාවක වෙනස් කළ හැකිය. සිදුවන එකම දෙය නම් එය පරිශීලකයින්ගේ කුකීස් වලංගු නොවන බවයි.

මට නම්, wp-configලේඛනයෙන් ඉවත් වීම ආරක්‍ෂාව පිළිබඳ අපැහැදිලි බවින් හෙළි වේ - එය පිදුරු මිනිසෙකි.

මම හිතන්නේ මැක්ස්ගේ දැනුමැති පිළිතුරක් වන අතර එය කතාවේ එක් පැත්තකි. මෙම වර්ඩ්ප්රෙස් කෝඩෙක්ස් වැඩි උපදෙස් ඇත :

එසේම, ඔබට (සහ වෙබ් සේවාදායකයාට) පමණක් මෙම ගොනුව කියවිය හැකි බවට වග බලා ගන්න (සාමාන්‍යයෙන් එයින් අදහස් කරන්නේ 400 හෝ 440 අවසරයකි).

ඔබ .htaccess සහිත සේවාදායකයක් භාවිතා කරන්නේ නම්, ඒ සඳහා සැරිසරන ඕනෑම කෙනෙකුට ප්‍රවේශ වීම ප්‍රතික්ෂේප කිරීම සඳහා ඔබට මෙම ගොනුවේ (ඉහළින්ම) තැබිය හැකිය:

<files wp-config.php>
order allow,deny
deny from all
</files>

Wp-config.php හි 400 හෝ 440 අවසරය සැකසීම මඟින් ප්ලගීන ලිවීම හෝ වෙනස් කිරීම වළක්වා ගත හැකි බව සලකන්න. නිදසුනක් ලෙස අව්‍යාජ නඩුවක් වනුයේ, හැඹිලි ප්ලගීන (W3 මුළු හැඹිලිය, WP සුපර් කෑෂ්, ආදිය) එවැනි අවස්ථාවක, මම 600 ක් සමඟ යන්නෙමි ( /home/userඩිරෙක්ටරියේ ගොනු සඳහා සුපුරුදු අවසරය ).

කවුරුහරි අපෙන් බැබළෙන්නැයි ඉල්ලා සිටි අතර මම මෙහි පිළිතුරු දෙන්නෙමි.

ඔව්, ඔබේ වෙබ් අඩවියේ මූල නාමාවලියෙන් ඔබේ wp-config.php හුදකලා කිරීමෙන් ආරක්ෂක ප්‍රතිලාභ ඇත.

1- ඔබේ PHP හසුරුවන්නා යම් ආකාරයකින් කැඩී හෝ වෙනස් වී ඇත්නම්, ඔබේ DB තොරතුරු නිරාවරණය නොවනු ඇත. ඔව්, සේවාදායක යාවත්කාල කිරීම් අතරතුර හවුල් ධාරක වල මෙය කිහිප වතාවක් සිදුවන බව මම දුටුවෙමි. ඔව්, එම කාලය තුළ වෙබ් අඩවිය බිඳී යනු ඇත, නමුත් ඔබගේ මුරපද නොවෙනස්ව පවතී.

2- හොඳම භාවිතයන් සැමවිටම නිර්දේශ කරන්නේ වින්‍යාස ගොනු දත්ත ගොනු වලින් හුදකලා කිරීමයි. ඔව්, වර්ඩ්ප්‍රෙස් (හෝ ඕනෑම වෙබ් යෙදුමක්) සමඟ එය කිරීම දුෂ්කර ය, නමුත් එය ඉහළට ගෙනයාම ටිකක් හුදකලා වේ.

3- PHP-CGI අවදානම මතක තබා ගන්න, ඕනෑම කෙනෙකුට? -S ගොනුවකට යැවිය හැකි අතර මූලාශ්‍රය බලන්න. http://www.kb.cert.org/vuls/id/520827

අවසානයේදී, ඒවා කුඩා විස්තර වේ, නමුත් ඒවා අවදානම අවම කිරීමට උපකාරී වේ. විශේෂයෙන් ඔබ හවුල් පරිසරයක සිටී නම්, ඕනෑම කෙනෙකුට ඔබේ දත්ත ගබඩාවට ප්‍රවේශ විය හැකිය (ඔවුන්ට අවශ්‍ය වන්නේ පරිශීලකයෙකු / සාමාර්ථයක් පමණි).

වෙබ් අඩවියක් නිසි ලෙස ආරක්‍ෂා කර ගැනීමට අවශ්‍ය දේ ඉදිරියේ කුඩා අවධානය වෙනතකට යොමු කිරීමට ඉඩ නොදෙන්න.

1- එය සැමවිටම යාවත්කාලීනව තබා ගන්න

2- ශක්තිමත් මුරපද භාවිතා කරන්න

3- ප්‍රවේශය සීමා කරන්න (අවසර හරහා). අපට ඒ ගැන ලිපියක් මෙහි ඇත:

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

ස්තූතියි,

අනිවාර්යයෙන්ම ඔව්.

ඔබ wp-config.php පොදු නාමාවලියෙන් පිටත ගෙන යන විට, php හසුරුවන්නා අනිෂ්ට ලෙස (හෝ අහම්බෙන්!) වෙනස් වූ විට ඔබ එය බ්‍රව්සරය භාවිතයෙන් කියවීමෙන් ආරක්ෂා කරයි.

කොර පරිපාලකගේ දෝෂයක් නිසා සේවාදායකයාට කිසිසේත්ම ආසාදනය නොවන විට ඔබේ ඩීබී පිවිසුම / මුරපදය කියවිය හැකිය. පරිපාලකයාට දඩ මුදලක් අය කර වඩා හොඳ සහ විශ්වාසදායක සේවාදායක සත්කාරක සමාගමක් ලබා ගන්න. එය වඩා මිල අධික විය හැකි වුවත්.

ඔබේ wp_config.php ගොනුව ගෙනයාම අනිවාර්යයෙන්ම මව් නාමාවලිය වෙත පමණක් ගෙන යා යුතු යැයි අදහස් නොකෙරේ යැයි තර්ක කිරීම සඳහා මට පැහැදිලි කිරීමට අවශ්‍යය. ඔබට / root / html වැනි ව්‍යුහයක් ඇති බව කියමු, එහිදී html හි WP ස්ථාපනය සහ ඔබේ සියලුම HTML අන්තර්ගතයන් අඩංගු වේ. Wp_config.php / root වෙත ගෙනයාම වෙනුවට, ඔබට එය / root / safe වැනි දෙයකට ගෙන යා හැකිය ... එය html නාමාවලියෙන් පිටත වන අතර සේවාදායක මූල නාමාවලියෙහි නොවේ. ඇත්ත වශයෙන්ම, මෙම ආරක්ෂිත ෆෝල්ඩරයේ ද php ධාවනය කළ හැකි බවට ඔබ සහතික විය යුතුය.

/ Root / safe වැනි සහෝදර සහෝදරියන්ගේ ෆෝල්ඩරයක wp_config.php සෙවීම සඳහා WP වින්‍යාසගත කළ නොහැකි බැවින්, ඔබ අතිරේක පියවරක් ගත යුතුය. මම wp_config.php / root / html හි දමා සංවේදී කොටස් (දත්ත සමුදා පිවිසුම, ලුණු, වගු උපසර්ගය) කපා ඒවා වෙනම ගොනුවකට config.php ලෙස ගෙන ගියෙමි. ඉන්පසු ඔබ includeඔබේ wp_config.php වෙත PHP විධානය එක් කරයි ,include('/home/content/path/to/root/secure/config.php');

මෙය මගේ සැකසුම තුළ මම කළ දෙයයි. දැන්, ඉහත සාකච්ඡාව මත පදනම්ව, එය අවශ්‍යද, හොඳ අදහසක්ද යන්න මම තවමත් ඇගයීමට ලක් කරමි. නමුත් මට අවශ්‍ය වූයේ ඉහත වින්‍යාසය හැකි බව එක් කිරීමට ය. එය ඔබගේ උපස්ථ සහ වෙනත් මූල ලිපිගොනු නිරාවරණය නොකරන අතර ආරක්ෂිත ෆෝල්ඩරය තමන්ගේම පොදු URL සමඟ සකසා නොමැති තාක් කල් එය ගවේෂණය කළ නොහැක.

තවද, .htaccess ගොනුවක් සෑදීමෙන් ඔබට ආරක්ෂිත ෆෝල්ඩරයට ප්‍රවේශය සීමා කළ හැකිය:

order deny,allow
deny from all
allow from 127.0.0.1

නරක ලිඛිත තේමාවන් සහ ප්ලගීන රාශියක් ඇත, එමඟින් atatckers හට කේත එන්නත් කිරීමට ඉඩ ලබා දේ (Timthumb සමඟ ඇති ආරක්ෂක ගැටළුව මතක තබා ගන්න). මම ප්‍රහාරකයෙකු නම්, මම wp-config.php සෙවිය යුත්තේ ඇයි? මෙම කේතය සරලව එන්නත් කරන්න:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

ඔබේ wp-config.php සැඟවීමට උත්සාහ කළ හැකිය. වර්ඩ්ප්‍රෙස් සියළුම සංවේදී තොරතුරු ගෝලීයව ප්‍රවේශ කළ හැකි තාක් කල්, wp-config.php සැඟවීමට කිසිදු ප්‍රතිලාභයක් නොමැත.

Wp-config.php හි නරක කොටස එය සංවේදී දත්ත රඳවා තබා ගැනීම නොවේ. නරක කොටස නම් සංවේදී දත්ත ගෝලීය ප්‍රවේශ විය හැකි නියතයක් ලෙස අර්ථ දැක්වීමයි.

යාවත්කාලීන කරන්න

define()සංවේදී දත්ත ගෝලීය නියතයක් ලෙස අර්ථ දැක්වීම නරක අදහසක් වන්නේ ඇයි සහ ඇයි යන්න පිළිබඳ ගැටළු පැහැදිලි කිරීමට මට අවශ්‍යය .

වෙබ් අඩවියකට පහර දීමට බොහෝ ක්‍රම තිබේ. ස්ක්‍රිප්ට් එන්නත් කිරීම යනු වෙබ් අඩවියක් ඇල්ලීමට ඇති එක් ක්‍රමයක් පමණි.

සේවාදායකයාට අනාරක්ෂිත බවක් ඇතැයි උපකල්පනය කිරීමෙන් ප්‍රහාරකයාට මතක ඩම්ප් එකකට ප්‍රවේශ විය හැකිය. ප්‍රහාරකයා විසින් සියලු විචල්‍යයන්ගේ සියලු අගයන් මතකයේ දමනු ඇත. ඔබ ගෝලීයව ප්‍රවේශ විය හැකි නියතයක් අර්ථ දක්වන්නේ නම්, ස්ක්‍රිප්ට් එක අවසන් වන තුරු එය මතකයේ රැඳී සිටිය යුතුය. නියතයක් වෙනුවට විචල්‍යයක් නිර්මාණය කිරීම, විචල්‍යය තවදුරටත් අවශ්‍ය නොවන පසු කසළ එකතු කරන්නා මතකය නැවත ලිවීමට (හෝ නිදහස්) හොඳ අවස්ථාවක් තිබේ.

සංවේදී දත්ත ආරක්ෂා කිරීමට වඩා හොඳ ක්‍රමයක් නම් එය භාවිතා කළ වහාම ඒවා මකා දැමීමයි:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

සංවේදී දත්ත භාවිතා කිරීමෙන් පසුව, පැවරීම nullමඟින් මතකයේ ඇති දත්ත නැවත ලියනු ලැබේ. $db_conසංවේදී දත්ත අඩංගු මොහොතේම ප්‍රහාරකයෙකුට මතක ඩම්ප් ලබා ගත යුතුය . ඉහත උදාහරණයේ එය ඉතා කෙටි කාලයකි (පංතියේ දත්ත සමුදාය_ හැන්ඩ්ලර් එහි පිටපතක් සුරැකෙන්නේ නැත්නම්).

ආරක්ෂක ප්‍රතිලාභ වලට අමතරව, ඔබේ වර්ඩ්ප්‍රෙස් උදාහරණය අනුවාද පාලනය යටතේ තබා ගැනීමටත්, මූලික වර්ඩ්ප්‍රෙස් ලිපිගොනු උප මොඩියුලයක් / බාහිර ලෙස තබා ගැනීමටත් එය ඉඩ දෙයි. මාර්ක් ජැකිත් සිය වර්ඩ්ප්‍රෙස්-ඇටසැකිල්ල ව්‍යාපෘතිය සකසා ඇත්තේ එලෙසිනි. වැඩි විස්තර සඳහා https://github.com/markjaquith/WordPress-Skeleton#assumptions බලන්න.