Реклама




Опросы

Каких скриптов не хватает ?

Просмотреть результаты

Загрузка ... Загрузка ...

Помощь проекту

 

WMID 133443326071

R341885382783

Payeer

P63968199

 

Свежие комментарии

Последние сообщения на форуме

 Обратите внимание что все скрипты взяты из открытых источником и я проверяю их только на наличие критических ошибок, потому вероятность вредоносных кодов и чужих ссылок очень высока по мере сил я исправляю  скрипты  но нет никакой гарантии что в дальнейшем в работе скриптов не будет проблем. Особо стоит обратить внимание на подключение автовыплат к скриптам ферм как показала практика они очень уязвимы. Не забудьте проверить скрипт на уязвимость 

6 самых распостраненных ошибок php

И снова о наболевшем о самых распостраненных ошибках.

6 самых распостраненных ошибок php

1. НЕ ОБЕСПЕЧИТЬ SQL CODE

Некоторые из лучших кибер-атак в Интернете — это инъекции SQL. В атаке SQL инъекции хакер введет SQL код, который вы не авторизировали в свою базу данных, в результате чего он выполняет команды, такие как утечка, изменение или удаление данных. Однако есть способы улучшить программирование PHP, чтобы свести к минимуму риск атаки SQL инъекций.

PHP является основой для нескольких готовых решений, таких как WordPress . При написании новых расширений и плагинов для сайтов WordPress разработчики, скорее всего, создадут встроенные операторы SQL. Эти утверждения построены из интерфейсного интерфейса и отправлены обратно в базу данных SQL. Если эти утверждения неверны, вы рискуете оставить свой сайт открытым для SQL инъекции.

Есть два способа избежать этого. Первый способ (и наиболее предпочтительный) заключается в использовании подготовленных инструкций. Второй — с помощью параметризованных запросов.

Следующий оператор основывается на пользовательском вводе из формы:

$stmt = ("SELECT * FROM users WHERE firstname = '".$firstname."';");

Это может привести к уязвимости вашего сайта, поскольку он оставляет ваш сайт открытым для SQL инъекции. Более безопасная ставка часто используется в параметризованных и подготовленных операциях, таких как:

$stmt = $dbConnection->prepare('SELECT * FROM users WHERE firstname = ?');

$stmt->bind_param('s', $firstname);
$stmt->execute();

Они считаются лучшими методами, потому что отметка галочки для открытия и закрытия строкового значения в SQL обрабатывается как литерал, а не символ открытия или завершения.

PHP имеет разные уровни ошибок, но вы можете вручную их подавить в своем коде. Это полезно, если у вас есть ошибки, которые не являются критическими и не вызывают серьезных последствий. Например, вы можете подавлять предупреждающие сообщения о версиях PHP.

Символ «@» используется для подавления ошибок, когда они вам не нужны, но используйте их с осторожностью — иногда это может вызвать некоторые непредвиденные проблемы. Предположим, у вас есть файл include, который не нужен при запуске приложения. Он может быть необязательным для пользователей, которые имеют только определенный компонент в своем браузере. В этом случае вы можете использовать следующий код в своем файле PHP:

(@include("animation.php"))

В приведенном выше коде, даже если файл animation.php имеет ошибки, они не будут отображаться или регистрироваться. Это подавление ошибок должно использоваться экономно, поскольку вы можете иметь ошибки, которые не регистрируются и не будут найдены до тех пор, пока в приложении не произойдет что-то критическое. В долгосрочной перспективе лучше обрабатывать ошибки, а не подавлять их для удобства.

3. ПРЯМАЯ ПЕЧАТЬ ДАННЫХ С ПОЛЬЗОВАТЕЛЬСКОГО ВВОДА

Эта ошибка одна из самых распостраненных и несколько напрямую связана с первой ошибкой, которую мы указали. Первая ошибка — не обеспечение кода SQL — может привести к нарушениям безопасности SQL-инъекций . Эта ошибка указывает на недостатки безопасности межсайтового скриптинга (XSS), которые могут возникать, когда разработчик печатает данные непосредственно у пользователя.

Предположим, у вас есть текстовое поле ввода формы с именем «firstname». Вы хотите, чтобы ваш скрипт отображал «Hello, $ firstname» для зрителя. Вы можете сделать это, используя следующий код:

Welcome <?php echo $_POST["firstname"]; ?>

Однако что произойдет, если пользователь вводит « <script>alert('hello');</script>»? Это может показаться незначительным, незначительным раздражением, которое никто бы не делал, но проблема в том, что вы разрешаете JavaScript работать без разбора в браузере. Когда JavaScript может запускаться в браузере с пользовательского ввода, злоумышленник может использовать XSS для выполнения любого количества событий, таких как кража паролей и сеансов. Хакер может стать очень креативным со сценарием и выполнить ряд атак, включая захват сеанса, фишинг и скрытую переадресацию.

Вместо того, чтобы печатать пользовательский ввод, убедитесь, что вы удаляете любые теги HTML из вывода, особенно теги скриптов. Это предотвратит запуск JavaScript-кода на вашем компьютере пользователя. Этот тип атаки называется атакой XSS, и он позволяет злоумышленнику запускать JS-код, который потенциально может поставить под угрозу все приложение.

4. НЕ ЗАБЫВАЙТЕ УДАЛЯТЬ КОНФИГУРАЦИИ РАЗРАБОТКИ

Для любого разработчика важно иметь среду разработки — промежуточную среду, которая имитирует производственную среду, в которой размещается код в реальном времени. В некоторых случаях разработчик может быть брошен и забыть удалить переменные и конфигурации разработки, а затем загрузить их случайно в производственную среду. Это может быть катастрофой для живого приложения.

Многие новые разработчики пытаются пропустить промежуточную среду и перейти от разработки к производству, чтобы сэкономить время. Это ошибка, потому что постановка может помочь вам выявить проблемы, которые вы не обнаружили в процессе разработки (помните, что постановка имитирует производство). Если вы случайно забыли удалить конфигурации или не находите ошибок до этапа, вы все равно сможете их поймать, прежде чем они попадут в производственную среду.

Всегда иметь промежуточную среду и использовать ее, даже если вы делаете минимальные изменения. Также неплохо, чтобы тестировщики QA тестировали код в процессе, прежде чем он перешел на производство.

5. СЛУЧАЙНОЕ ИСПОЛЬЗОВАНИЕ ОПЕРАТОРА ПРИСВАИВАНИЯ, А НЕ СРАВНЕНИЕ УСЛОВИЙ

Легко случайно использовать неправильный оператор при написании операторов условий. В конце концов, разработчики могут потратить несколько часов на присвоение значений переменным. Однако, если вы случайно используете оператор присваивания вместо условного сравнения, вы рискуете ввести ошибки.

Возьмите этот код, например:

if ($condition = 'value')
//do something

В приведенном выше коде разработчик ошибочно присваивает значение «значение» переменной $ condition. Условие должно выглядеть следующим образом:

if ($condition == 'value')
//do something

Чтобы избежать такого рода ошибок, некоторые разработчики предпочитают использовать синтаксис yoda. Синтаксис Yoda переключает порядок состояния и значения. Это то, что приведенный выше код будет выглядеть в синтаксисе yoda:

if ('value' == $condition)
//do something

Теперь, если вы случайно используете оператор присваивания вместо сравнения, компилятор даст вам ошибку, и вы можете исправить ошибку.

6. ОТКАЗ ОТ ЗАПУСКА РЕЗЕРВНЫХ КОПИЙ

Это может показаться легким шагом, но многие разработчики имеют плохие методы резервного копирования. Вам не нужно создавать резервные копии каждый час, но вы должны запускать резервные копии каждый день, если вы выполняете значительную работу над проектом. Просто помните, что ваши резервные копии сохраняют ваши часы перекодировки, если вы потеряете свои данные в случае сбоя вашего диска.

Если вам сложно определить проблему в коде, выполните резервное копирование системы, чтобы вы не потеряли решение — и часы работы — и должны его перекодировать. Резервная копия также может спасти вас от отсутствия крайнего срока, если что-то случится, чтобы пойти наперекосяк.

Вы также должны создавать резервные копии для своих клиентов в редком случае, когда клиент имеет критический сбой и нет резервной копии. Это хороший жест, и вы можете помочь своему клиенту выйти из потенциально липкой ситуации.

ВЫВОД

Многие разработчики сталкиваются с этими распространенными ошибками при изучении PHP. Это часть процесса обучения при изучении нового языка. Как с чем-либо, практика делает совершенным. После того, как вы допустили ошибку, вы можете узнать об этом и принять меры, чтобы избежать повторения той же ошибки в ваших будущих приложениях. Некоторые из них будут критическими, а другие будут незначительными, но этот список поможет вам избежать некоторых из наиболее распространенных.