Some Wordpress plugins (one is MapPress which uses Google Maps) use ampersands in their links but do not convert them into the correct HTML character entity:
&
This invalidates the markup and is very frustrating!
Is there any way to convert the & to &?
I've searched for a long time and found no solution, but have read a lot of interesting articles on the topic!
I think you're looking for htmlentities: http://php.net/manual/en/function.htmlentities.php
<?php
$str = "A 'quote' is <b>bold</b>";
// Outputs: A 'quote' is <b>bold</b>
echo htmlentities($str);
// Outputs: A 'quote' is <b>bold</b>
echo htmlentities($str, ENT_QUOTES);
?>
I'd write an email to him and ask him to use htmlentities in his plugin. Even better, make the changes yourself, then email him a patch.
Related
I've encountered an issue that I've never come across before with Silverstripe when saving content in the CMS.
When saving in the Content wysiwyg (or any other fields I've added), it is escaping the quotes and apostrophies ie. When applying a style to a piece of content through the style dropdown to make the underlying HTML:
<p class="my-style">lorem ipsum</p>
When I press save, the page reloads and the style is not shown. When inspecting the HTML put back into the wysiwyg, I am getting:
<p class="\"my-style\"">lorem ipsum</p>
Initially, my thoughts were that the content field was maybe set to Text rather than HTMLText but I've checked and found this not to be the case.
Anyone have any ideas? I've built numerous sites in Silverstripe previously and this is the first time I've encountered this behaviour.
I'm using 3.1.0
Cheers
As I've mentioned I think this is a PHP issue and an issue of escaping double/single quotes. It's a symptom of magic quotes.
Magic Quotes was a "(annoying) security feature" enabled by default in PHP < 5.3.0 and deprecated in > 5.4.0
In a jist here's what magic quotes does (taken from php website)
When on, all ' (single-quote), " (double quote), \ (backslash) and NULL characters are escaped with a backslash automatically. This is identical to what addslashes() does.
This may be what you are experiencing.
Disabling Magic Quotes
On to the solution.
If you have access to your main php.ini, just turn it off like so:
; Magic quotes
;
; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = Off
; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
magic_quotes_runtime = Off
; Use Sybase-style magic quotes (escape ' with '' instead of \').
magic_quotes_sybase = Off
If you don't have have access to the main php.ini:
add this line to the root .htaccess file (if you're using apache mod_php)
php_flag magic_quotes_gpc Off
or if you're running PHP as a CGI, create a php.ini file on your document root and put the previously mentioned snippet for php.ini.
Hope this helps!
Very peculiar...
I read the symtpoms as a double double quote, if you parse
<p class="\"my-style\"">lorem ipsum</p>
it's going to appear as
<p class=""my-style"">lorem ipsum</p>
I usually define my styles in the typography.css file and it automatically appears in the "Styles" drop-down in the WYSIWYG editor.
Can you try this out and let me know if it helps?
Thanks!
When a user fills out a form how do I go about escaping the user input in express.js?
Does express.js do this by default? I can't find a source.
Do I have to use a third-party module like express-validator.js?
UPDATE
I figured out the difference between escaping and validating.
What I wanted to do was escape user input but what I should be doing is validating it, making sure it's in a valid format and then escape the output to the form if it is not valid providing the user exactly what they inputted.
<%= some_html %> will automatically escape it. <%- some_html %> will output html intact.
Exactly what kind of escaping do you need to do? Express will automatically decode (not unescape) the query string for you and make it available as req.query. URL params will also be unencoded for you automatically.
If you need to escape HTML that includes user input when rendering, you should do that via your template engine. Most template engines such as jade (= value) or handlebars or mustache ({{value}}) will escape HTML by default, and require an explicit syntax to pass data through unescaped ( != value in jade or {{{value}}} in handlebars/mustache).
I want to use mpdf to create my PDF-files because I use norwegian letters such as ÆØÅ. The information on the PDF-file would mostly consist of text written by the user in a HTML form. But, I have some problems.
When using this code:
$mpdf->WriteHTML('Text with ÆØÅ');
The PDF will show the special characters.
But when using this:
<?php
include('mpdf/mpdf.php');
$name = 'Name - <b>' . $_POST['name'] . '</b>';
$mpdf = new mPDF();
$mpdf->WriteHTML($name);
$mpdf->Output();
exit;
?>
The special characters will not show.
The HTML form looks like this:
<form action="hidden.php" method="POST">
<p>Name:</p>
<input type="text" name="name">
<input type="submit" value="Send"><input type="reset" value="Clear">
</form>
Why won't the special characters show with this method? And which method should I use?
Since echoing the POST-data back onto the website does not show the characters as well, this clearly isn't an issue with mpdf. When using content including non-Ascii characters, special care about the websites character encoding has to be taken.
From the mpdf-documentation it can be seen that it supports UTF-8 encoding, so you might want to use that for your data. POST-data is received in the same encoding that is used by the website. So if the website is in latin-1, you will need to call utf8_encode() to convert the POST-data to unicode. If the website already uses UTF-8 you should be just fine.
If you don't set a specific encoding in the website header (which you should always to avoid this kind of trouble), encoding might depend on several factors such as the operating system and configuration on the server or the encoding of the original php sourcefile which, as it turns out, is influenced by your own OS configuration and choice of editor.
I am using php, mysql with smarty and I places where users can put comments and etc. I've already escaped characters before inserting into database for SQL Injection. What else do I need to do?
XSS is mostly about the HTML-escaping(*). Any time you take a string of plain text and put it into an HTML page, whether that text is from the database, directly from user input, from a file, or from somewhere else entirely, you need to escape it.
The minimal HTML escape is to convert all the & symbols to & and all the < symbols to <. When you're putting something into an attribute value you would also need to escape the quote character being used to delimit the attribute, usually " to ". It does no harm to always escape both quotes (" and the single quote apostrophe '), and some people also escape > to >, though this is only necessary for one corner case in XHTML.
Any good web-oriented language should provide a function to do this for you. For example in PHP it's htmlspecialchars():
<p> Hello, <?php htmlspecialchars($name); ?>! </p>
and in Smarty templates it's the escape modifier:
<p> Hello, {$name|escape:'html'}! </p>
really since HTML-escaping is what you want 95% of the time (it's relatively rare to want to allow raw HTML markup to be included), this should have been the default. Newer templating languages have learned that making HTML-escaping opt-in is a huge mistake that causes endless XSS holes, so HTML-escape by default.
You can make Smarty behave like this by changing the default modifiers to html. (Don't use htmlall as they suggest there unless you really know what you're doing, or it'll likely screw up all your non-ASCII characters.)
Whatever you do, don't fall into the common PHP mistake of HTML-escaping or “sanitising” for HTML on the input, before it gets processed or put in the database. This is the wrong place to be performing an output-stage encoding and will give you all sort of problems. If you want to validate your input to make sure it's what the particular application expects, then fine, but weeding out or escaping “special” characters at this stage is inappropriate.
*: Other aspects of XSS are present when (a) you actually want to allow users to post HTML, in which case you have to whittle it down to acceptable elements and attributes, which is a complicated process usually done by a library like HTML Purifier, and even then there have been holes. Alternative, simpler markup schemes may help. And (b) when you allow users to upload files, which is something very difficult to make secure.
In regards to SQL Injection, escaping is not enough - you should use data access libraries where possible and parameterized queries.
For XSS (cross site scripting), start with html encoding outputted data. Again, anti XSS libraries are your friend.
One current approach is to only allow a very limited number of tags in and sanitize those in the process (whitelist + cleanup).
You'll want to make sure people can't post JavaScript code or scary HTML in their comments. I suggest you disallow anything but very basic markup.
If comments are not supposed to contain any markup, doing a
echo htmlspecialchars($commentText);
should suffice, but it's very crude. Better would be to sanitize all input before even putting it in your database. The PHP strip_tags() function could get you started.
If you want to allow HTML comments, but be safe, you could give HTML Purifier a go.
You should not modify data that is entered by the user before putting it into the database. The modification should take place as you're outputting it to the website. You don't want to lose the original data.
As you're spitting it out to the website, you want to escape the special characters into HTML codes using something like htmlspecialchars("my output & stuff", ENT_QUOTES, 'UTF-8') -- make sure to specify the charset you are using. This string will be translated into my output & stuff for the browser to read.
The best way to prevent SQL injection is simply not to use dynamic SQL that accepts user input. Instead, pass the input in as parameters; that way it will be strongly typed and can't inject code.
I'm having some trouble getting CGI.pm to output to HTML5 instead of XHTML 1.0 or HTML 4.01. When I try "HTML5" or "HTML 5" as the -dtd argument in start_html() I get a document in HTML 4. I've also tried importing :HTML5, but that doesn't seem to work either. Any advice?
The correct doctype for HTML 5 is just "html", not "html5" or "html 5", and does not use a DTD. CGI.pm only supports well-formed DTDs, not arbitrary strings. Since the HTML 5 doctype does not include a well-formed DTD, CGI.pm (as of the current version, 3.49) does not support the HTML 5 doctype.
Using CGI.pm's HTML-generation functions is generally frowned upon these days. Templating systems such as Template::Toolkit or HTML::Template are preferred for their ability to cleanly separate your code's logic from the formatting of its output. They also, incidentally, allow you to specify whatever doctype and code to whatever version of (X)HTML you choose.
Here's a fragment from some code where I 'solved' this problem using brute force.
# $html is accumulator for HTML string
my $html;
# <html> tag and <head> section
my $dtd = '<!DOCTYPE html>'; # HTML5 DTD
my $title = "Storage analysis of $HOSTNAME as of $TODAY";
$html .= start_html(
-title => $title,
-style => {
-code => $css,
}
);
# KLUDGE: CGI.pm doesn't support HTML5 DTD; replace the one it puts in.
$html =~ s{<!DOCTYPE.*?>}{$dtd}s;
Here are some Perl5 frameworks that are HTML5 friendly:
Catalyst http://www.catalystframework.org/
Dancer http://perldancer.org/documentation
Mojolicious http://mojolicio.us/
I'm leaning toward using Mojolicious for my newest Perl project.
All of these are more relevant for robust HTML5 apps than the CGI module. CGI still has its place and is still developed/supported but it does not address robust HTML5 apps as well as some of the frameworks that are out there.
Patch the module to add support for HTML5 … or just output a Doctype manually, then use it as normal. If it is valid XHTML 1.0 or HTML 4.01 then it is valid HTML 5.