Jump to content

HTML Transmission Using the $_POST Superglobal


iwato

Recommended Posts

This is another strategy question.  Multiple answers are welcome.  What is written in present tense should be thought of as future, not yet realized activity.

BACKGROUND:  I have constructed a form whose intended purpose is to create chunks of data including text, links, and images that can be entered into a MySQL database for both immediate and future use.  For the moment, I am only concerned about their immediate use.

From the database these same chunks of data are retrieved and entered into an HTML template that serves as the backbone for an email insert that is, in fact, a weekly newsletter that can be viewed directly in one's mailbox or viewed on line should the insert fail.  The mail insert is then distributed using PHPMailer that takes advantage of an assembled list of subscribers stored in the same database.

Based on previous experience I believe that I am well able to handle this routine except for one hitch -- the treatment of the HTML data.

MY DILEMMA:  In the form are <textarea> elements that I intend to fill with a combination of plain text, HTML, and CSS styling attributes.  That the HTML does not render as anything but the code itself is not a cause for concern on my part.  Rather, I am bothered about how to send this data to the remote server.  Now, I have been taught to filter and sanitize $_POST variable data as it is received and before processing.  This time, however, I am sending the data to myself, and what will be generated and sent to my subscribers will also be generated by me.

Do I even need to worry how about filtration and sanitation when I am both the source and the receiver of the data?  Further, it is my understanding that MySQL is indifferent how the data is received, and that it will automatically return data in the same format that it is received.  Am I making a big ado about nothing?

By the way, it is not just a matter of filtration and sanitization.  Take, for example, the following script used to process form data on the same page that it is entered.

<form id="sevengates" method="post" action="<?php echo htmlspecialchars($_SERVER['PHP_SELF']);?>">

 

Edited by iwato
Link to comment
Share on other sites

Say, I enter the following line of code into a <textarea> element in the same manner that it appears below.

<h3>Q&A</h3>

is there any reason that I would have to encode it using the htmlspecialchars( ) method before sending it to the MySQL database.  Recall that upon retrieval from the database, it will be inserted into an HTML page.

Link to comment
Share on other sites

IF it is not going Joe public who can submit ANYTHING, but just you, or someone with Authorization then No, but you can limit the type of html code (such as '<h1><a><p>') that can be submitted using strip_tags(), if not listed, they will be removed even <script> and <?php.

Using ' <h3>Q&A</h3>' will convert it to &lt;h3&gt;Q&amp;A&lt;/h3&gt; and without being decoded with htmlspecialchars_decode() will show exactly as <h3>Q&A</h3> NOT as

Q&A

But you could limit the information submitted, input for title, sub title, content, images, then you control what html tags are used for the Newsletter and where/how this information is used.

Edited by dsonesuk
Link to comment
Share on other sites

Thank you, Dsonesuk, for responding.

It is good to know that I can avoid the normal security procedures.

The second part of my question, however, is the need for encoding and decoding the HTML.

Recall that my goal is to have appear in my HTML template exactly what I write in my <textarea> element.  In other words, I want the recipient of the email insert to see Q&A, but in my template I wish to see exactly what I type into my <textarea> element -- namely,  <h3>Q&A</h3>.

The transmission path is

1) <textarea> on locally created form

2) $_POST variable sent to PHP file on remote server.

3) Insertion of the contents of the <textarea> into the HTML template via the PHP file on the remote server

4) SMTP transmission to subscribers mailbox with the modified HTML template included.

In other words, at only one point do I want the code <h3>Q&A</h3> to appear as Q&A with <h3> element highlighting.  

QUESTION:  Must I encode the HTML script as HTML entities before sending the $_POST variable and then decode the entities as HTML script after the transmission? If so, why?  If not, I understand. 

Edited by iwato
Link to comment
Share on other sites

If you actually want the HTML to be rendered, then no sanitization is needed at all. If you want to literally see all the tags then you would use htmlspecialchars() right before putting the data into the HTML template.

There's no need to sanitize it for storage even when you want to prevent HTML injection. You sanitize it only right before using it.

Link to comment
Share on other sites

Ingolme:  I still do not understand.

I will surely use code similar to the following to fetch my HTML template before attaching it to the mail that I will send to my subscribers.

$html_message = file_get_contents('../../confirmation_mail.php');
$html_message = str_replace('%username%', $name, $html_message);
$html_message = str_replace('%email%', $email, $html_message);
$html_message = str_replace('%hash%', $hash, $html_message);
				
$mail->msgHTML($html_message);

At this point is the file still not an unrendered HTML file?

The story with which I started this query has changed somewhat since I wrote it.  My current, more reflected intention is to to do the following:

When the completed form data arrives at the remote server from my local test server via the $_POST variable two things will happen: one, a large portion of the information will be placed into the HTML template before being sent out as an email insert to my subscribers; and two, the entirety of the data will be archived in various tables in my remote host server account's MySQL data base.

My assumption is that the data that I type into my form's <textarea> -- namely, <h3>Q&A</h3> will appear everywhere the same, just as you see it now.  Everywhere refers to the contents of the <textarea> element, the $_POST variable, the MySQL database tables, and the HTML template before it is sent.  If this is true, why would any encoding or decoding of the HTML code be necessary?

Edited by iwato
Link to comment
Share on other sites

If you want to see "<h3>Q&A</h3>" instead of "Q&A" then you should pass it through htmlspecialchars() before putting it into the template any anywhere else were you will be using it.

$html_message = str_replace('%something%', htmlspecialchars($something), $html_message);

 

Link to comment
Share on other sites

Ingolme:  I understand the code that you have written, but I am having trouble with your English.  Please allow me to help by passing your response through a series of true/false questions.

QUESTION ONE:  My assumption is that the data that I type into my form's <textarea> -- namely, <h3>Q&A</h3> will appear everywhere the same, just as you see it now.  Everywhere in this interpretation refers to the contents of the

  • the <textarea> form element,
  • the $_POST variable, and
  • the MySQL database tables

I am assuming no explicit modification of the HTML script on my part.

Is this statement true or false?

Edited by iwato
Link to comment
Share on other sites

That's true. The $_POST variable and the database table will have exactly the same content that you typed into the textarea.

What you have to watch out for is that if you put the content of the $_POST variable into an environment that reads HTML (a browser or e-mail client) it will parse the HTML.

Link to comment
Share on other sites

QUESTION TWO: Because

  • the data that reside in the $_POST variable are the same that reside in the <textarea> element, and
  • the data that reside in the HTML template are all in unrendered HTML script

when I pass the data from the $_POST variable to the HTML template no explicit modification of the code is needed on my part.

True or False?

Please be patient with my insistence, as I am truly confused.

Edited by iwato
Link to comment
Share on other sites

It strictly depends on what you want to see.

From what I've read in your previous posts, you actually want angle brackets ("<" and ">") to appear in your e-mail. You need to sanitize the $_POST variable when you put it into the template.

There are two different environments you're working with:

  • Environments that use plain text (Database, PHP backend)
  • Environments that use HTML (Browsers and e-mail clients)

For environments that use plain text, no sanitization is needed. When you put the variables into an environment that uses HTML then you have to sanitize it.

Link to comment
Share on other sites

Ingolme:  The HTML Template unless rendered is filled with HTML script:  <h3>, <p>, <table>, &, etc.  When I pass the information contained in the $_POST variable to this file why must it be altered?  Should it not look just like all of the rest of the code in the file -- i.e., the same as it appears in the initial <textarea> element of the form from which it arose?  This 

$html_message = str_replace('%something%', htmlspecialchars($something), $html_message);

makes no sense to me in the context that I have provided.  Indeed, whatever encoding need to be performed so that the email insert appears correctly in the subscribers email box appears to be performed by the PHPMailer's 

$mail->msgHTML($html_message);

function.  Does this not appear reasonable?

Link to comment
Share on other sites

If you are adding html through a secure form whose access is only achievable through logging on and accessing through username password, then save html content as entered in textarea to database table field, that is how CMS does it. IT then reads that data containing html tags back to page or newsletter, which if email must be in a table structured layout.

The images must be saved on server and reference with absolute path NOT relative, or be an encoded image file.

IF the form is accessible from none secured area that is when sanitization needs to be taken.

IF this page is not linked to in anyway, it can still be found and used to inject code IF NOT accessible ONLY by logging into the form page.

Link to comment
Share on other sites

Ingolme:  The end-users (the recipients of the email insert) should see the highlighted Q&A text -- not the HTML that creates it.

Donesuk:  I followed you until your last sentence, but believe that everything essential was already said.  I believe to be on a clear track now, but will not know for sure until I have succeeded with the implementation.

So, for now, thanks to you both!  I will be back with a report of success or failure, but am momentarily engaged in another routine that I wish to consummate first. 

Link to comment
Share on other sites

The last sentence is when you created the form page and thinking that you alone know the full url address to access that page, because that page is not linked to from any other page, that it would be undiscoverable and therefore safe, is untrue.

Link to comment
Share on other sites

Dsonesuk:  The form page is local.  It is on my test server and likely not accessible to the average user.

Link to comment
Share on other sites

  • 1 month later...

I have finally completed my other project and am ready to return to this one.  In the interim I was able to discuss the matter with my web host and was told the following:

The Apache server settings permit only those files that are linked to the my site's index page -- either directly or indirectly through other pages that are linked to the index page -- are visible.  This is to say that all unlinked pages result in the 404 error code.

This suggests that I can place a file on my site that processes $_POST variables that I send to it from my local server without fear of manipulation from third parties.  

Please allow me to state clearly my intention and then comment on it with reflection on our previous discussion and any new security issues that come to mind.

1) I have created a form that on my local server that draws data from my local server.

2) This data will be sent to a page on my web host via a $_POST variable.

3) The page to which it is sent will process the received $_POST variable and send the results to my accounts database via SMTP.

4) Another page on my web host will take a portion of the same data from the database via SMTP,  complete the template,  and distributes the completed template via email to my websites subscribers.

Roddy

 

Link to comment
Share on other sites

This suggests that I can place a file on my site that processes $_POST variables that I send to it from my local server without fear of manipulation from third parties.

I don't think so, I think the only reason they would do that is so that someone can't upload a malicious PHP file or something and just run it without there being a link to it somewhere.  I'm assuming they actually search through all of the files and their output for URLs instead of just relying on the referer header.  That seems like a really intensive process though.

It's kind of a weird requirement, but it sounds like if you want that page to be accessible then you have to edit your index file and put a link to that page.

Link to comment
Share on other sites

Based upon your suggestion JSG I do not believe that you have understood the problem.  I have no trouble accessing files that are not linked to my site's index page.  If I have understood my web host properly correctly, they are claiming simply that the files just described are not visible to others.

Link to comment
Share on other sites

It seems that way, does it not?  Now, I do not claim to know everything that a web server can know, but I do know that certain kinds of information can be obtained once a connection has been established. 

Roddy

Link to comment
Share on other sites

Unless specifically programmed otherwise, the server will serve the same content to everybody. If you have a PHP file that can manipulate files or the database then it's open for everybody to use and is an easy attack vector on your website, if you want to prevent other people from using it you will have to add some form of authentication.

In summary, nothing is stopping me from sending a POST request to your web host.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...