I am trying to create a link that navigates to a 3rd party site and automatically logs in.
There is no API and the form doesn't support query strings. Security isn't an issue (I know passing variables in links isn't good practice but in our situation that's ok).
I can get it to work using VBS but IE makes it really tough to execute scripts.
I am now using Javascript:
function autoLogin() {
document.Form1.submit();
}
My HTML:
<form name="namofform" method=post action="www.websiteofloginpage.com">
<input type=hidden id=ID name="USERNAME" value="USERNAME"/>
<input type=hidden id=ID name="PASSWORD" value="PASSWORD"/>
</form>
I change the fields to the one on the form. When I execute the script (on load or by a link) it navigates to the page but isn't posting (logging in).
I noticed the submit button is using the _doPostBack - is that why it's not working trying from my a different site?
Have you looked into other cross-domain POSTing answers? There are certainly a variety of ways you can circumvent the same origin policies of browsers, but you won't be able to do it with simple JavaScript POSTing of forms.
See more here:
Cross Domain Form POSTing
Perhaps you can use a CORS-based or JSONp solution:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
What is JSONP all about?
Did you try to submit form with the good URI, generally we will have something like that: www.example.com/login. There also another point mentionned in Jim Miller's answer which is the Cross Domain Form POSTing.
Related
I am currently working on a page where I need the user to input several variables which when submitted are then displayed throughout the page.
Problem is, it needs to be 100% secure code and whilst I'm ok using PDO/mysql etc javascript is not something I'm very fluent in.
At the moment, I have the following:
<script language="JavaScript">
function showInput() {
document.getElementById('var1').innerText =
document.getElementById("user_var1").value;
document.getElementById('var2').innerText =
document.getElementById("user_var2").value;
}
</script>
with the html
<form>
your variable 1 is = <input type="text" name="message" id="user_var1"><br />
your variable 2 is = <input type="text" name="message" id="user_var2"><br />
</form>
<input type="submit" onclick="showInput();">
<p>var1 = <span id='var1'></span></p>
<p>var2 = <span id='var2'></span></p>
From what I can tell, using ".innerText" should stop any html etc being used and I have tested with
<script>alert(document.cookie);</script>
which results in the above just being printed as is (not run).
e.g.
your variable 1 is = <script>alert(document.cookie);</script>
Is there anything else you would recommend doing to make sure it is secure (XSS or otherwise)? Only characters that should need to be entered are / and A-Z 0-9
Thanks in advance :)
edit
Just to clarify, the only code is what is above, the page is not pulling data from a database etc (what you see above is virtually the full php page, just missing the html head body tags etc).
Just based on what you're doing above you're not going to have XSS. innerText will do proper escaping.
To have your site be 100% secure is a tall order. Some of the things I'd look at are running your site over HTTPS with HSTS to prevent a network level adversary tampering with the site, parameterizing your SQL queries, adding CSRF tokens as necessary on form submission.
Specifically regarding XSS, one of the most common ways people get XSS'd is because they perform insecure DOM manipulation. If you're concerned about security I'd highly recommend porting your JS to React as you're manipulating a "virtual DOM", which allows React to perform context sensitive escaping. It also takes the burden off of the developer from having to do proper escaping.
One quick security win is adding a CSP policy to your site and setting the script-src directive to self. A CSP policy establishes the context in which certain content can run on your site. So if for example, you have script-src set to self (meaning your JS is loaded in the src attribute of a <script> tag pointing to the same domain as where the HTML is served, and not inline on the page) if someone does XSS it will (most likely*) not run.
These are just some examples of different security solutions available to you and a brief intro to security-in-depth practices. I'm glad you're taking security seriously!
*There are some circumstances (if you're dynamically generating your scripts for example) in which their code could run.
There is no vulnerability here (please read before downvote).
Just to clarify, the only code is what is above, the page is not
pulling data from a database etc (what you see above is virtually the
full php page, just missing the html head body tags etc).
Therefore the following two fields cannot be populated by anything other than the current user:
<input type="text" name="message" id="user_var1">
<input type="text" name="message" id="user_var2">
because there is no code present that populates these two fields.
The two DOM elements that are populated by code are as follows:
<span id='var1'></span>
<span id='var2'></span>
The code which does this is
document.getElementById('var1').innerText =
document.getElementById("user_var1").value;
document.getElementById('var2').innerText =
document.getElementById("user_var2").value;
It is using the non-standard innerText rather than textContent, however innerText will set the text content rather than HTML content, preventing the browser from rendering any tags or script.
However, even if it was setting the innerHTML property instead, all the user could do is attack themselves (just the same as they would opening up developer tools within their browser).
However, in the interests of correct functional behaviour and internet standards, I would use textContent rather than innerText or innerHTML.
Note that
<script>alert(document.cookie);</script>
would not work anyway, it would have to be
<svg onload="alert(document.cookie)" />
or similar. HTML5 specifies that a <script> tag inserted via innerHTML should not execute.
I want to upload a file from an jsp page, I know the basics.
<form name="someForm" id="someFormId" method="post" enctype="multipart/form-data">
<input type="file" name="somename" size="chars">
<input id="anyid" name="anyName" type="submit" value="UploadFile" class="button" />
I want to make a progress bar of some kind but I don't know if its possible, I read that you can do it using flash, but it would be a mess using flash on the project just for that thing.
Is there any way of capturing the progress of the load?
Thanks for reading
Not like this. Basically JavaScript has to be in control of sending the file for it to be able to report a progress. If you just do a post request your only progress indicators are 'loading' and 'done'.
Using the FileReader object and FormData object you can have JavaScript send a file and get progress results. It doesn't work in older browsers though so be cautious.
Google for more info, there are some standard solutions out there.
You can do this only if the browser supports one of several methods. Either FileReader/FormData (as Frits mentioned), or via Flash or another browser plugin. You also need to do the post handling server-side.
I'm using Plupload at work in a number of areas where this type of functionality was needed. I'm using a slightly modified version of the jQueryUI script/css. It works very well, and the plugin/script author has already handled the heavy lifting for the client-side work.
NOTE: for straight html+javascript posts without flash, or limiting supported browsers, the best you can do is display an animated flash (animated gifs stop animating in the browser) as part of the "onsubmit" action for the form.
I'm interfacing a page that needs a login with mechanize. It uses some javascript on the front page making using mechanize straight-up more difficult. I know what form I have to submit to log-in - the one always generated by the js, the same every time. How can I make mechanize just submit a custom form that isn't on the page? Basically equivalent to this perl problem but in Python.
(NOTE: This came up again recently and I actually got it to work now.)
This seems to work:
br.open(URL)
res = mechanize._form.ParseString(FORM_HTML, BASE_URL)
br.form = res[1]
#continue as if the form was on the page and selected with .select_form()
br['username'] = 'foo'
br['password'] = 'bar'
br.submit()
URL is the full URL of the visited site. BASE_URL is the directory the URL is in. FORM_HTML is any HTML that has a form element, e.g.:
<form method='post' action='/login.aspx'>
<input type='text' name='username'>
<input type='text' name='password'>
<input type='hidden' name='important_js_thing' value='processed_with_python TM'>
</form>
For some reason, mechanize._form.ParseString returns two forms. The first is a GET request to the base URL with no inputs; the second, the properly parsed form from FORM_HTML.
Parse the page, extract the elements you want, reform the page, and inject them back into mechanize.
For a project I worked on, I had to employ a simulated browser and found Mechanize to be very poor at form handling. It would yank uninterpreted elements out of Javascript blocks and die. I had to write a workaround that used BeautifulSoup to strip out all the bits that would cause it to die before it reached the form parser.
You may or may not run into that problem, but it's something to keep in mind. I ultimately ended up abandoning the Mechanize approach and went with Selenium. It's form handler was far superior and it could handle JS. It's got its issues (the browser adds a layer of complexity), but I found it much easier to work with.
In WebKit I get the following error on my JavaScript:
Refused to execute a JavaScript script. The source code of script found within request.
The code is for a JavaScript spinner, see ASCII Art.
The code used to work OK and is still working correctly in Camino and Firefox. The error only seems to be thrown when the page is saved via a POST and then retrieved via a GET. It happens in both Chrome/Mac and Safari/Mac.
Anyone know what this means, and how to fix this?
This "feature" can be disabled by sending the non-standard HTTP header X-XSS-Protection on the affected page.
X-XSS-Protection: 0
It's a security measure to prevent XSS (cross-site scripting) attacks.
This happens when some JavaScript code is sent to the server via an HTTP POST request, and the same code comes back via the HTTP response. If Chrome detects this situation, the script is refused to run, and you get the error message Refused to execute a JavaScript script. Source code of script found within request.
Also see this blogpost about Security in Depth: New Security Features.
Short answer: refresh the page after making your initial submission of the javascript, or hit the URL that will display the page you're editing.
Long answer: because the text you filled into the form includes javascript, and the browser doesn't necessarily know that you are the source of the javascript, it is safer for the browser to assume that you are not the source of this JS, and not run it.
An example: Suppose I gave you a link your email or facebook with some javascript in it. And imagine that the javascript would message all your friends my cool link. So, the game of getting that link to be invoked becomes simply, find a place to send the javascript such that it will be included in the page.
Chrome and other WebKit browsers try to mitigate this risk by not executing any javascript that is in the response, if it was present in the request. My nefarious attack would be thwarted because your browser would never run that JS.
In your case, you're submitting it into a form field. The Post of the form field will cause a render of the page that will display the Javascript, causing the browser to worry. If your javascript is truly saved, however, hitting that same page without submitting the form will allow it to execute.
As others have said, this happens when an HTTP response contains a JavaScript and/or HTML string that was also in the request. This is usually caused by entering JS or HTML into a form field, but can also be triggered in other ways such as manually tweaking the URL's parameters.
The problem with this is that someone with bad intentions could put whatever JS they want as the value, link to that URL with the malicious JS value, and cause your users trouble.
In almost every case, this can be fixed by HTML encoding the response, though there are exceptions. For example, this will not be safe for content inside a <script> tag. Other specific cases can be handled differently - for example, injecting input into a URL is better served by URL encoding.
As Kendall Hopkins mentioned, there may be a few cases when you actually want JavaScript from form inputs to be executed, such as creating an application like JSFiddle. In those cases, I'd recommend that you you at least scrub through the input in your backend code before blindly writing it back. After that, you can use the method he mentioned to prevent the XSS blockage (at least in Chrome), but be aware that it is opening you to attackers.
I used this hacky PHP trick just after I commit to database, but before the script is rendered from my _GET request.:
if(!empty($_POST['contains_script'])) {
echo "<script>document.location='template.php';</script>";
}
This was the cheapest solution for me.
I've been at this for several days and searches including here haven't give me any solutions yet.
I am creating a Bookmarklet which is to interact with a POST API. I've gotten most of it working except the most important part; the sending of data from the iframe (I know horrible! If anyone knows a better solution please let me know) to the javascript on my domain (same domain as API so the communication with the API is no problem).
From the page the user clicks on the bookmarklet I need to get the following data to the javascript that is included in the iFrame.
var title = pageData[0].title;
var address = pageData[0].address;
var lastmodified = pageData[0].lastmodified;
var referralurl = pageData[0].referralurl;
I first fixed it with parsing this data as JSON and sending it through the name="" attribute of the iFrame but realized on about 20% of webpages this breaks. I get an access denied; also it's not a very pretty method.
Does anyone have anyidea on how I can solve this. I am not looking to use POSTS that redirect I want it all to be AJAX and as unobtrusive as possible. It's also worth noting I use the jQuery library.
Thank you very much,
Ice
You should look into easyXDM, it's very easy to use. Check out one of the examples on http://consumer.easyxdm.net/current/example/methods.html
After a lot of work I was able to find a solution using JSONP which is enables Cross Domain Javascript. It's very tricky with the Codeigniter Framework because passing data allong the URLs requires a lot of encoding and making sure you dont have illegal characters. Also I'm still looking to see how secure it really is.
If I understand your question correctly, you might have some success by looking into using a Script Tag proxy. This is the standard way to do cross domain AJAX in javascript frameworks like jquery and extjs.
See Jquery AJAX Documentation
If you need to pass data to the iframe, and the iframe is actually including another page, but that other page is on the same domain (a lot of assumptions, I know).
Then the man page code can do this:
DATA_FOR_IFRAME = ({'whatever': 'stuff'});
Then the code on the page included by the iframe can do this:
window.parent.DATA_FOR_IFRAME;
to get at the data :)