I am trying to test one of my php sanitization classes against a few xss scripts available on
http://ha.ckers.org/xss.html
So one of the scripts in there has perl in it, is this some kind of a perl statement?? And would this execute directly on the server, since perl is a server scripting language.
perl -e 'print "<IMG SRC=java\0script:alert(\"XSS\")>";' > out
Is the script that I am trying to work with. I have not tested it yet though, but I want to understand before I use it.
The \0 is a string termination character in the laguage C. Since perl is built on top of C, in the old days you could inject this "poisonous null byte" to make the C part read the line
<IMG SRC=java instead of the whole string, and thus maybe allow the whole thing through even though you were trying to strip stuff like SRC=javascript:
Mostly this doesn't work anymore because the higher level languages has gotten pretty good at defeating attacks like this by stripping out stray control chars like \0 before sending the strings on to the lower level routines.
You can read more on the poison nullbyte here: http://insecure.org/news/P55-07.txt or here: http://hakipedia.com/index.php/Poison_Null_Byte
The Perl isn't the attack, it just demonstrates how to generate the attack, since you can't see it in a plain string.
The point is that there is a null character (represented in Perl as \0) in the data.
Related
In PHP, you can (since PHP 5.2.1) use "binary strings":
$binary = (binary) $string;
$binary = b"binary string";
What is the difference with a "normal" string?
The only meaningful insight I could find was this comment:
However, it will only have effect as of PHP 6.0.0, as noted on http://www.php.net/manual/en/function.is-binary.php .
The link is dead. It would actually make sense that binary strings were added in PHP while PHP 6.0 was being developed, since 6.0 was supposed to bring Unicode support. So it was sort of a premature feature.
However is there an official source that could confirm that? I.e. confirm that there is absolutely no difference between classic strings and binary strings?
I don't have any official source to back this up, but I believe the reason is simple:
The present PHP treats strings as byte arrays, i.e. as raw binary blobs. PHP 6 was slated to be this great new release with its biggest improvement being native Unicode handling. At that point, a string literal would actually be understood as a string of characters instead as a string of bytes. Many string handling functions would break because of this and a lot of code would need to be retrofitted to continue to work in PHP 6.
As a migration path, strings could be declared as binary strings to keep the current behaviour. This was added early on to give developers ample time to prepare their code for PHP 6 compatibility. At the moment b doesn't do anything, the changed behaviour would only show up in PHP 6.
Well, PHP 6 never happened and is dead for now. So, b continues to do nothing for the time being and for now it's questionable if it will ever have any specific use in the future.
So, I am studying some PHP security using DVWA (http://www.dvwa.co.uk/). Right now I'm on an exercise where the author tries to teach us to execute commands on vulnerable applications. In this level, it adds a very simple blacklist which removes important characters:
$substitutions = array(
'&&' => '',
';' => '',
);
I obviously can use some other characters to still get code executed (like |, ||, &, etc.), but I wanted to know how I'd evade the substitution for the single character ";". I've seen some examples around which fools the substitution with code like "<scr<script>ipt>" and I've tried stuff like ";;;"; tried to encode in hex and base64 and such but it didn't work.
Is there a way to evade str_replace() when it is looking for a single character? This is PHP 5.5.3.
I found this page to be useful when I was doing this. It turns out there are other operators which can be used other than ';' to plug your own command in!
The "hard" setting on this is currently causing myself some trouble, I think there may be a workaround using URL encoded characters or something of the sort, but it remains to be seen.
I'm not sure why the author is showing how to use a black-list, its too easily subverted, perhaps this idea is shredded further on in the tut. http://en.wikipedia.org/wiki/Secure_input_and_output_handling
Although the example you link to is the 'medium' level, even the 'harder' level does not use PHPs Filter FILTER_VALIDATE_IP
Even a REGEX would do a better job. See half way down the page of: http://www.regular-expressions.info/examples.html
If you are trying to protect against XSS attacks (you mention a mangled script tag) then white-listing is the way to go. Validate against what you expect to get, or abort.
EDIT
Hmmm.. now I see the site is called Damned Vulnerable Web App, perhaps the idea is to teach you all the poor examples ...
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How can I convert a string from windows-1252 to utf-8 in Ruby?
How can i transform the utf8 chars to iso8859-1
So here's my problem. I have tools I've distributed across my internal LAN and my external web servers serve up jobs/data to the internal LAN. As a result I'm often passing data I'd rather snoopy people didn't see. In other words, it's not the end of the world if someone sees my SQL string but I'd rather they didn't. I know, it's like a deadbolt on a sliding glass door. It won't keep anyone truly determined out but it should discourage the random curious script kiddie.
So I have a set of simple ciphers I've written in PHP. Recently I've determined that my next extension to my toolset needs to be in Ruby but those new tools need to communicate with my previously built set of PHP tools - I don't want to rebuild all of the PHP tools. So I need my PHP ciphers to be exactly reproduced by my Ruby code so that when Ruby encrypts a string my PHP tools and decipher it, then pass back an encrypted string for my Ruby tools to decipher.
My simple ciphers are just modified Caesar ciphers. A Caesar cipher (for those unfamiliar with the name) is where you shift all characters by a single known number of letters - i.e. a shift of 3 turn A into D, B into E, C into F, etc. A true Caesar cipher would require wrapping so that a shift of 3 would turn a Z into a C. However, mine doesn't do that, it simply adds 3 to Z and uses the utf8_encode and utf8_decode functions in PHP.
Now I need an equivalent in Ruby. I thought I'd found it in
str.encode('utf-8')
But that returns this error
undefined method 'encode' for #
My Googling suggests there is no single solution to this in Ruby for some reason. Ruby needs to know the current encoding of the string before encoding it into UTF-8. At least that's the way I understood the issue.
So the string coming in would be whatever Ruby 1.8.7 defaults to. (In case this is useful... I'm using Ubuntu 12.04 desktop, US, English and I think I grabbed Ruby using apt-get with the default repositories.) I need a variety of strings like SQL query statements - "SELECT * FROM table WHERE id = ?" and strings produced by PHP's md5() output. Every other string should fall into the category of upper case letters, lower case letters, and numbers all of it in US English.
Thanks
Check out Encoding and look at the documentation for the encode method you're using.I believe it is the first form that you need.
Are there any pre-made scripts that I can use for PHP / MySQL to prevent server-side scripting and JS injections?
I know about the typical functions such as htmlentities, special characters, string replace etc. but is there a simple bit of code or a function that is a failsafe for everything?
Any ideas would be great. Many thanks :)
EDIT: Something generic that strips out anything that could be hazardous, ie. greater than / less than signs, semi-colons, words like "DROP", etc?
I basically just want to compress everything to be alphanumeric, I guess...?
Never output any bit of data whatsoever to the HTML stream that has not been passed through htmlspecialchars() and you're done. Simple rule, easy to follow, completely eradicates any XSS risk.
As a programmer it's your job to do it, though.
You can define
function h(s) { return htmlspecialchars(s); }
if htmlspecialchars() is too long to write 100 times per PHP file. On the other hand, using htmlentities() is not necessary at all.
The key point is: There is code, and there is data. If you intermix the two, bad things ensue.
In the case of HTML, code is elements, attribute names, entities, comments. Data is everything else. Data must be escaped to avoid being mistaken for code.
In case of URLs, code is the scheme, the host name, the path, the mechanism of the query string (?, &, =, #). Data is everything in the query string: parameter names and values. They must be escaped to avoid being mistaken for code.
URLs embedded in HTML must be doubly escaped (by URL-escaping and HTML-escaping) to ensure proper separation of code and data.
Modern browsers are capable of parsing amazingly broken and incorrect markup into something useful. This capability should not be stressed, though. The fact that something happens to work (like URLs in <a href> without proper HTML-escaping applied) does not mean that it's good or correct to do it. XSS is a problem that roots in a) people unaware of data/code separation (i.e. "escaping") or those that are sloppy and b) people that try to be clever about what part of data they don't need to escape.
XSS is easy enough to avoid if you make sure you don't fall into categories a) and b).
I think Google-caja maybe a solution. I write a taint analyzer for java web application to detect and prevent XSS automatically. But not for PHP. I think Learning to using caja not bad for web developer.
No, there isn't. Risks depend on what you do with data, you can't write something that makes data safe for everything (unless you want to discard most of the data)
is there a simple bit of code or a function that is a failsafe for everything?
No.
The representation of data leaving PHP must be converted / encoded specifically according where it is going. And therefore should only be converted/encoded at the point where it leaves PHP.
C.
You can refer to OWASP to get more understanding of XSS attacks:
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
To avoid js attacks, you can try this project provided by open source excellence:
https://www.opensource-excellence.com/shop/ose-security-suite.html
my website had the js attacks before, and this tool helps me block all attacks everyday. i think it can help you guys to avoid the problem.
Further, you can add a filter in your php script to filter all js attacks, here is one pattern that can do job:
if (preg_match('/(?:[".]script\s*()|(?:\$\$?\s*(\s*[\w"])|(?:/[\w\s]+/.)|(?:=\s*/\w+/\s*.)|(?:(?:this|window|top|parent|frames|self|content)[\s*[(,"]\s[\w\$])|(?:,\s*new\s+\w+\s*[,;)/ms', strtolower($POST['VARIABLENAME'])))
{
filter_variable($POST['VARIABLENAME']);
}
To answer to your edition: everything except <> symbols has nothing to do with XSS.
And htmlspecialchars() can deal with them.
There is no harm in the word DROP table in the page's text ;)
for clean user data use
html_special_chars(); str_replace() and other funcs to cut unsafe data.
We implemented the online service where it is possible to generate PDF with predefined
structure. The user can choose a LaTeX template and then compile it with an appropriate inputs.
The question we worry about is the security, that the malicious user was not able to gain shell access through the injection of special instruction into latex document.
We need some workaround for this or at least a list of special characters that we should strip from the input data.
Preferred language would be PHP, but any suggestions, constructions and links are very welcomed.
PS. in few word we're looking for mysql_real_escape_string for LaTeX
Here's some code to implement the Geoff Reedy answer. I place this code in the public domain.
<?
$test = "Test characters: # $ % & ~ _ ^ \ { }.";
header( "content-type:text/plain" );
print latexSpecialChars( $test );
exit;
function latexSpecialChars( $string )
{
$map = array(
"#"=>"\\#",
"$"=>"\\$",
"%"=>"\\%",
"&"=>"\\&",
"~"=>"\\~{}",
"_"=>"\\_",
"^"=>"\\^{}",
"\\"=>"\\textbackslash",
"{"=>"\\{",
"}"=>"\\}",
);
return preg_replace( "/([\^\%~\\\\#\$%&_\{\}])/e", "\$map['$1']", $string );
}
The only possibility (AFAIK) to perform harmful operations using LaTeX is to enable the possibility to call external commands using \write18. This only works if you run LaTeX with the --shell-escape or --enable-write18 argument (depending on your distribution).
So as long as you do not run it with one of these arguments you should be safe without the need to filter out any parts.
Besides that, one is still able to write other files using the \newwrite, \openout and \write commands. Having the user create and (over)write files might be unwanted? So you could filter out occurrences of these commands. But keeping blacklists of certain commands is prone to fail since someone with a bad intention can easily hide the actual command by obfusticating the input document.
Edit: Running the LaTeX command using a limited account (ie no writing to non latex/project related directories) in combination with disabling \write18 might be easier and more secure than keeping a blacklist of 'dangerous' commands.
According to http://www.tug.org/tutorials/latex2e/Special_Characters.html the special characters in latex are # $ % & ~ _ ^ \ { }. Most can be escaped with a simple backslash but _ ^ and \ need special treatment.
For caret use \^{} (or \textasciicircum), for tilde use \~{} (or \textasciitilde) and for backslash use \textbackslash
If you want the user input to appear as typewriter text, there is also the \verb command which can be used like \verb+asdf$$&\~^+, the + can be any character but can't be in the text.
In general, achieving security purely through escaping command sequences is hard to do without drastically reducing expressivity, since it there is no principled way to distinguish safe cs's from unsafe ones: Tex is just not a clean enough programming language to allow this. I'd say abandon this approach in favour of eliminating the existence of security holes.
Veger's summary of the security holes in Latex conforms with mine: i.e., the issues are shell escapes and file creation.overwriting, though he has missed a shell escape vulnerability. Some additional points follow, then some recommendations:
It is not enough to avoid actively invoking --shell-escape, since it can be implicitly enabled in texmf.cnf. You should explicitly pass --no-shell-escape to override texmf.cnf;
\write18 is a primitive of Etex, not Knuth's Tex. So you can avoid Latexes that implement it (which, unfortunately, is most of them);
If you are using Dvips, there is another risk: \special commands can create .dvi files that ask dvips to execute shell commands. So you should, if you use dvips, pass the -R2 command to forbid invoking of shell commands;
texmf.cnf allows you to specify where Tex can create files;
You might not be able to avoid disabling creation of fonts if you want your clients much freedom in which fonts they may create. Take a look at the notes on security for Kpathsea; the default behaviour seems reasonable to me, but you could have a per user font tree, to prevent one user stepping on another users toes.
Options:
Sandbox your client's Latex invocations, and allow them freedom to misbehave in the sandbox;
Trust in kpathsea's defaults, and forbid shell escapes in latex and any other executables used to build the PDF output;
Drastically reduce expressivity, forbidding your clients the ability to create font files or any new client-specified files. Run latex as a process that can only write to certain already existing files;
You can create a format file in which the \write18 cs, and the file creation css, are not bound, and only macros that invoke them safely, such as for font/toc/bbl creation, exist. This means you have to decide what functionality your clients have: they would not be able to freely choose which packages they import, but must make use of the choices you have imposed on them. Depending on what kind of 'templates' you have in mind, this could be a good option, allowing use of packages that use shell escapes, but you will need to audit the Tex/Latex code that goes into your format file.
Postscript
There's a TUGBoat article, Server side PDF generation based on LATEX templates, addressing another take on the question to the one I have taken, namely generating PDFs from form input using Latex.
You'd probably want to make sure that your \write18 is disabled.
See http://www.fceia.unr.edu.ar/lcc/cdrom/Instalaciones/LaTex/MiKTex/doc/ch04s08.html and http://www.texdev.net/2009/10/06/what-does-write18-mean/