Есть ли менее хакерский способ запроса конкретного аудиофайла через PHP, чем этот?
Мне нужен аудиофайл из вывода php-скрипта, чтобы поместить его в источник аудио-тега HTML. Я не могу указать какие, поскольку не могу добавить переменные POST, поэтому я делаю это, устанавливая SESSION «songRequested» посредством вызова ajax, а затем запрашивая файл и используя переменную сеанса, чтобы указать, какой файл необходим.
HTML
<audio id ="player">
<source src="" id = "source">
</audio>
JS
$.post('includes/songrequest.php',{'request':songName},function(){
$('#source').attr("src","includes/songrequest.php");
player.load();
player.play();
});
//Declare the session variable as the file you want and set the audio source to be the songrequest php below with the session variable as the file to be downloaded.
PHP
<?php
session_start();
if(!isset($_SESSION['u_uid'])){
exit();
}
if(isset($_POST['request'])){
$_SESSION['request'] = $_POST['request'];
//If requesting with post variables, set the session variable to it.
exit();
}
//Otherwise, retrieve the file set as the session variable
$file = dirname(getcwd(),2)."\\users\\".$_SESSION['u_uid']."\\".$_SESSION['
header('Content-Type: audio/'.pathinfo($file,PATHINFO_EXTENSION));
header('Cache-Control: no-cache');
header('Content-Transfer-Encoding: binary');
header('Content-Length: ' . filesize($file));
header('Accept-Ranges: bytes');
readfile($file);
Мне пришлось пойти на это, так как я не мог передать переменные post, когда я вызвал источник php в теге audio, и я не знаю способа действительно обработать аудиоданные изначально в javascript.
Решение
В ралли нет ничего более безопасного post затем get запрос. Оба могут быть подделаны против вашего сайта. Лучший способ сделать это, если вы спросите меня, это не использовать ни один из них, а вместо этого использовать сегмент URI. Я должен отметить, что это не более безопасно, чем отправлять или получать Основное преимущество URI заключается в том, что вы все равно можете использовать получение и публикацию данных, не путая их. И когда вы думаете об этом, логически это ресурс, который вы идентифицируете, поэтому использование только URL / URL имеет своего рода смысл.
URI — это часть URL, которая находится после «реального» расположения ресурсов. Примером будет
$('#source').attr("src","includes/songrequest.php/{songname}");
куда {songname} это URI запроса. Это обычно используется в средах MVC, которые передают все через главный index.php, Такие как www.example.com/index.php/some_controller/some_method, Часто этот факт скрывается путем перезаписи URL с помощью mod_rewrite (HTACCESS).
Теперь для доступа к этим данным вы можете посмотреть в $_SERVER Super Global, где должно быть что-то вроде $_SERVER['PATH_INFO'] (Я забыл с макушки головы). Возможно, вам придется обрезать некоторые косые черты или почистить их немного ..
Теперь о содержании этих данных. Я бы посоветовал даже не передавать имя файла, просто хэш или идентификатор или имя песни и т. Д. Затем вы используете это для поиска фактического пути. Это предотвратит использование ненужных путей, так как путь происходит из внутреннего источника данных, который просматривается той «частью» данных, которую вы передаете.
Таким образом, вы могли бы передать что-то вроде этого (если использовать красивый хэш)
$('#source').attr("src","includes/songrequest.php/2Bzi0U8t");
Затем вы ищите это значение в БД, получаете URL и начинаете.
Также я не думаю, что с этим просто что-то не так.
$('#source').attr("src","includes/songrequest.php?song=2Bzi0U8t");
Ключ здесь заключается в том, чтобы не передавать фактический путь, потому что он может быть использован трансверсалом каталога. Что, где хакер предоставляет что-то вроде этого в качестве пути
song=../../../somefile_we_dont_want_a_hacker_accessing.txt
В основном это позволяет им перемещаться по файловой системе и получать доступ к вещам, к которым они не должны иметь доступ. Но используя поиск для этого, худшее, что они могут сделать, — это поиск чего-то, уже сохраненного в вашей БД.
Имеет смысл.
Другие решения
Других решений пока нет …
detector