hello i was wondering what is the best way to upload a video to a website? should I do it through a page with GET and if so how is the file uploaded through http? i am a little confused as to how this would work? I am trying to upload files from iphone and android devices so i cannot use a form to do this, at least i don't think so is there a way to upload my file through http? or what is the most convenient way? thank you
The most pressing issue here is that the HTTP specification requires that GET requests be both safe and idempotent. Uploading video will likely be neither of these.
Section 9.1.1 Safe Methods in RFC 2616:
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval. These methods ought to be considered "safe".
This allows user agents to represent other methods, such as POST, PUT
and DELETE, in a special way, so that the user is made aware of the
fact that a possibly unsafe action is being requested.
So no, bandwidth has nothing to do with it. HTTP itself says you shouldn't be uploading any sort of file by way of the GET method.
GET does not allow for enough bandwidth for a video. Use POST or PUT instead.
The official standard (RFC 2616) states
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
So, uploading a video would not come under 'retrieving information'.
POST should be used, like this:
<form action="process.php" method="post">
Related
I am concerned about the safety of fetching content from unknown url in PHP.
We will basically use cURL to fetch html content from user provided url and look for Open Graph meta tags, to show the links as content cards.
Because the url is provided by the user, I am worried about the possibility of getting malicious code in the process.
I have another question: does curl_exec actually download the full file to the server? If yes then is it possible that viruses or malware be downloaded when using curl?
Using cURL is similar to using fopen() and fread() to fetch content from a file.
Safe or not, depends on what you're doing with the fetched content.
From your description, your server works as some kind of intermediary that extracts specific subcontent from a fetched HTML content.
Even if the fetched content contains malicious code, your server never executes it, so no harm will come to your server.
Additionally, because your server only extracts specific subcontent (Open Graph meta tags, as you say),
everything else that is not what you're looking for in the fetched content is ignored,
which means your users are automatically protected.
Thus, in my opinion, there is no need to worry.
Of course, this relies on the assumption that the content extraction process is sound.
Someone should take a look at it and confirm it.
does curl_exec actually download the full file to the server?
It depends on what you mean by "full file".
If you mean "the entire HTML content", then yes.
If you mean "including all the CSS and JS files that the feched HTML content may refer to", then no.
is it possible that viruses or malware be downloaded when using curl?
The answer is yes.
The fetched HTML content may contain malicious code, however, if you don't execute it, no harm will come to you.
Again, I'm assuming that your content extraction process is sound.
Short answer is file_get_contents is safe you retrieve data, even curl is. It is up to you what you do with that data.
Few Guidelines:
1. Never Run eval on that data.
2. Don't save it to database without filtering.
3. Don't even use file_get_contents or curl.
Use: get_meta_tags
array get_meta_tags ( string $filename [, bool $use_include_path = false ] )
// Example
$tags = get_meta_tags('http://www.example.com/');
You will have all meta tags parsed, filtered in an array.
you can use httpclient.class instead of file_get_content or curl. because it connect's the page through the socket.After download the data you can take the meta data using preg_match.
Expanding on the answer made by Ray Radin.
Tips on precautionary measures
He is correct that if you use sound a sound process to search the fetched resource there should be no problem in fetching whatever url is provided. Some examples here are:
Don't store the file in a public facing directory on your webserver. Then you expose yourself to this being executed.
Don't store it in a database, this might lead to a second order sql injection attack
In general, don't store anything from the resource you are requesting, if you have to do this use a specific whitelist of what you are searching for
Check the header information
Even though there is no foolprof way of validating what you are requesting with a specific url. There are ways you can make your life easier and prevent some potential issues.
For example a url might point to a large binary, large image file or something similar.
Make a HEAD request first to get the header information. Then look at the Content-type and Content-length headers to see if the content is a plain text html file
You should however not trust these since they can be spoofed. Doing this will hovewer make sure that even non-malicous content won't crash your script. Requesting image files is presumably something you don't want users to do.
Guzzle
I recommend using Guzzle to do your request since it is in my opinion provides some functionallity that should make this easier
It is safe but you will need to do a proper data check before using it. As you should with any data input anyway.
I'm coding an API and got stuck on the UPDATE part of things. From what I've read about REST the update operation should be exposed by using HTTP PUT.
Ok, PUT gives me just a stream of data. At least in PHP the decoding of this data is my responsibility. So how do I mix string data and file upload and use PUT? I know I can do it in POST but I'm trying to do it the RESTful way.
Should I use multipart/form-data and is that portable for PUT (I mean is it easy to send this kind of request in different languages)? I'm trying to figure out the proper way to do this. Again, if I use multipart/form-data I'm responsible for the parsing so there might be some errors or performance degradation. Can you suggest a parser if this multipart/... is the way to do what I'm asking?
Thanks
General rule of PUT is that is idempotent
Calling 2x PUT /user/{userId}/files/foo.txt ends up in the same state, with the 2nd call you would simply override the foo.txt. You are 'setting' things.
Calling 2x POST /user/{userId}/files would end up in two different files. You are 'adding' things.
Therefore I would use PUT if you want to write to a dedicated target. What kind of files do you want to upload. E.g. if it is a picture-upload I would use POST (where you would get the target url inside response). If you are designing a kind of file-storage for a user I would use PUT, because most likely users want to write (set) to a certain location (like you would on a ordinary file-system).
Maybe you have more details/requirements for a concrete case?
What kind of data are you attempting to PUT? Remember that PUT is a directed publishing method. The client sends data to the server and essentially says "PUT this file into /home/sites/.../myfile.txt".
Useful for when you're publishing data to a site and are creating a new page. Not so useful if it's a standard file upload form ("Upload an avatar image here!"). You don't want to allow potentially malicious users to specify where an uploaded file should go.
That's when you use POST, which translates into "here's a file, it's called myfile.txt, do what you want with it".
Bbcode question. This:
$text = preg_replace("#\[img\](.*)\[\/img\]#si",
"<img src=\"$1\" border=\"0\" />", $text);
works fine, but at the same time it's a big security problem, for example:
[img]http://www.domain.com/delete-account/[/img]
or
[img]http://www.domain.com/logout/[/img]
Any ideas how to control this so that only image links which ends with .jpg are being converted into html?
[img]http://www.domain.com/image.jpg[/img]
Thanks.
According to the HTTP1.1 standard, requesting URLs with GET (the method used to acquire images) should not result in any actions, such as logout. Therefore, you don't need to restrict to URLs with a .jpg at the end, and in general, it is a bad idea because there are other image formats, and the URL is in general unrelated to its content type.
More to the point, if requesting a URL does change a state of a server vulnerable.net, this Cross Site Request Forgery Vulnerability can be exploited anyway by setting up a custom server that 302-redirects http://evil.com/img.jpg to http://vulnerable.net/logout.
FYI, if you really wanted to replace only URLs ending with .jpg, you can just insert it in the group:
$text = preg_replace("#\[img\](.*\.jpg)\[\/img\]#si",
"<img src=\"$1\" border=\"0\" />", $text);
But this is not a security mechanism, and fails if the browser (or a aggressively caching proxy, or a virus scanner, or ...) prefetches URLs. GET requests should not result in any action.
One way to think about this problem is as well to check on server side that GEt and POST request are not equivalent.
A POST request can alter data in server side, a GET request musn't change anything. That's the HTTP protocol. An IMG tag is a GET request, always. And the browser can perform this GET request without any risk, so the problem is on server side, every action that can change alter data (database, session, etc) must check the request is a POST one. For example your /post or /delete-account url, should return either a 403 or a 200 code but with a form page, asking for a POST confirmation. If this is wrong in your application, then you'll have problems not only with altered IMG tags, but maybe as well with 'html page speeders' that make preload of GET referecnes, or even bots.
If you can find a copy of this excellent book you may find some advanced image links problems and filtering tricks. For example links on foreign websites can sometime be a problem. But this is a problem far more complex than starting by handling GET and POST requests in a convenient way.
I need to confirm something before I go accuse someone of ... well I'd rather not say.
The problem:
We allow users to upload images and embed them within text on our site. In the past we allowed users to hotlink to our images as well, but due to server load we unfortunately had to stop this.
Current "solution":
The method the programmer used to solve our "too many connections" issue was to rename the file that receives and processes image requests (image_request.php) to image_request2.php, and replace the contents of the original with
<?php
header("HTTP/1.1 500 Internal Server Error") ;
?>
Obviously this has caused all images with their src attribute pointing to the original image_request.php to be broken, and is also the wrong code to be sending in this case.
Proposed solution:
I feel a more elegant solution would be:
In .htaccess
If the request is for image_request.php
Check referrer
If referrer is not our site, send the appropriate header
If referrer is our site, proceed to image_request.php and process image request
What I would like to know is:
Compared to simply returning a 500 for each request to image_request.php:
How much more load would be incurred if we were to use my proposed alternative solution outlined above?
Is there a better way to do this?
Our main concern is that the site stays up. I am not willing to agree that breaking all internally linked images is the best / only way to solve this. I refuse to tell our users that because of something WE changed they must now manually change the embed code in all their previously uploaded content.
Ok, then you can use mod_rewrite capability of Apache to prevent hot-linking:
http://www.cyberciti.biz/faq/apache-mod_rewrite-hot-linking-images-leeching-howto/
Using ModRwrite will probably give you less load than running a PHP script. I think your solution would be lighter.
Make sure that you only block access in step 3 if the referer header is not empty. Some browsers and firewalls block the referer header completely and you wouldn't want to block those.
I assume you store image paths in database with ids of images, right?
And then you query database for image path giving it image id.
I suggest you install MemCached to the server and do caching of user requests. It's easy to do in PHP. After that you will see server load and decide if you should stop this hotlinking thing at all.
Your increased load is equal to that of a string comparison in PHP (zilch).
The obfuscation solution doesn't even solve the problem to begin with, as it doesn't stop future hotlinking from happening. If you do check the referrer header, make absolutely certain that all major mainstream browsers will set the header as you expect. It's an optional header, and the behavior might vary from browser to browser for images embedded in an HTML document.
You likely have sessions enabled for all requests (whether they're authenticated or not) -- as a backup plan, you can also rename your session cookie name to something obscure (edit: obscurity here actually doesn't matter as long as the cookie is set for your host only (and it is)) and check that a cookie by that name is set in image_request.php (no cookie set would indicate that it's a first-request to your site). Only use that as a fallback or redundancy check. It's worse than checking the referrer.
If you were generating the IMG HTML on the fly from markdown or something else, you could use a private key hash strategy with a short-live expire time attached to the query string. Completely air tight, but it seems way over the top for what you're doing.
Also, there is no "appropriate header" for lying to a client about the availability of a resource ;) Just send a 404.
I read something about this on PHP docs, but it's not clear to me:
Do the most widely used browsers (IE, FF, Chrome, Safari, Opera, ...) support this PUT method to upload files?
What HTML should I write to make the browser call the server via a PUT request? I mean do I need to write a FORM with an INPUT file field and just replace the attribute method="POST"with method="PUT"?
On the PHP docs (link above) they say a PUT request is much simpler than a POST request when uploading file, along with this advantage, what other advantages/disadvanatges do the PUT has got compared to the POST?
The PUT method cannot be used from a <form>. MSIE does not support it through the user GUI at all.
You can however use XMLHttpRequest. It seems to be defined in the standard and WHATWG / HTML5. My browser (Opera) obviously likes it.
http://old.mnot.net/javascript/xmlhttprequest/
IE might work too, as a short Google search suggests. And Firefox looks fine. Not checked Chrome or Webkit.
Server-site you need a specially designated script to handle an incoming PUT request. Look into the Apache docs. A mod_rewrite rule might usually do.
The genral adavantage of PUT is that there is no file encoding / marshalling into a multipart/* mime type required. In theory this allows uploading larger files more reliably. Allthough if you use PHP, it won't help you much. It's meant for Webservers with WebDAV support and/or direct filesystem write access. (Apache can save uploaded files itself, if you use that.)
I think the method is supported by most major browsers, but you can't account for every browser and other client that is out there. From a cursory look at the user contributed notes, this sometimes even needs server-side configuration to work.
Also, handling any additional form values you may want to send along with your file becomes more difficult.
I wouldn't use it. Way too much possible hassle for little actual gain.
The fact that PUT is rarely used for the purpose and only supported by major browsers excludes it from the any possible use here.
PUT is not very widely supported by browsers, and isn't generally used for interactive HTML forms.