.htaccess keeps asking for password when serving up mp3 mime type 1

[1DMF]

Hi,

I'm building a members area and decided to use .htaccess authentication for member logins.

All works fine , my scripts and protected directories run fine once logged in and all seems dandy.

however, one script I have for serving up MP3's doesn't seem to acknowledge the user being looged in.

Everytime the script runs .htaccess requests the username and password again.

The only difference is this script outputs octet stream binary to the browser where as those that work without login prompts output text/html

Help resolving this is appreciated.

Regards,
1DMF.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[ChrisHirst]

.htaccess is read and parsed on every HTTP request and as your script runs in the context of the Linux useraccount NOT the "logged in user" account any HTTP requests the script makes will be intercepted.



Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[1DMF]

but the call to the script is made via a hyperlink and they are both using HTTP protocol.

I don't understand why one script in the protected directory doesn't required re-entering of password yet one that doesn't output text/html does? All scripts run in the context of the perl interpreter don't they?


There must be a way of making this work, people must be able to serve up MP3 files to members logged in via .htacccess.



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[ChrisHirst]

but the call to the script is made via a hyperlink and they are both using HTTP protocol.

Yep, but the script request is from a different user context.
The browser maintains state for the user authentication, but the scripting runs as the server user account NOT the account that the browser "knows" about.

people must be able to serve up MP3 files to members logged in via .htacccess.

I would think that most people these days would be using more sophisticated security methods.



Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[1DMF]

I still don't follow Chris. sorry if i'm being thick.

I have several scripts in the protected folder, they don't request user login repleatedly and one assumes all scripts run as the server user account.

So why is the returned content making the difference?

I'd expect it to happen on all scripts or no scripts but not selectively dependent on what is returned to the browser?

On a side note, what's wrong with apache .htaccess security?

Apart from the obvious basic authentication, I've yet to try digest which is encrypted.

Both use inbuilt apache .htaccess, is this no good?


"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[ChrisHirst]

There are exploits where the .htaccess file can be read or replaced by attackers, so using it for "mission critical" security is not recommended.

I would think that this is more of a coding question and how the scripts is requesting the resource, if some scripts run without problems and others don't.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[1DMF]

OK, I'll try the perl heads!

Thanks for the into, but I am rather suprised if it's a known exploit why apache haven't fixed it?

I thought apache was rock solid?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[ChrisHirst]

It's not always a direct Apache attack, "they" find and use various ways in, and as fast as you can remove the "doorway" the crackers will find another (or two), and if you run servers with Wordpress or Joomla users (because many "plugins" aren't written with security in mind), sleep almost becomes a luxury.

http://www.marksanborn.net/php/php-include-injection-and-google-referral-hijack/

and that's only one of them.


Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[1DMF]

Thanks for the link.

What I don't understand is how the hijacker was able to change the .htaccess.

This at first I thought had to be an FTP hack, how else can anyone get access to the .htaccess file?

The reading further it's because they broke the first golden rule of any CGI script.

Input data cleansing to stop code injection, be it SQL, includes, html, javascript or anything else.

That's not a hijacker being clever , that's the programmer not being diligent.

I understand that plugins might not be secure, and this all seems to be based on PHP, which I don't do anyhow, I write everything in perl by hand.

I learned from you guys a long time ago , cargo cult programming is bad and for major systems you should understand every line of code it includes!

Well obviously OOP, kinda breaks that argument as part of OO is code reuse, but i guess now with the advent of all these systems and plug-ins, the lessons are being learnt that code reuse when it's someones you don't know can be a very bad idea.

with that in mind one wonders how open source ever caught on?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[ChrisHirst]

What I don't understand is how the hijacker was able to change the .htaccess.

I wish I knew, four sites on our servers have been hit, two running Joomla 1.5 and the other two were plain HTML with no scripting at all.
What they had done in one case was plant a script file (base64decode) which seems to provide them with a rogue telnet server.

Grepping the cpanel logs showed external access to the cPanel file uploader for some of the suspect file names with a spoofed referrer, blank referrers are blocked from cPanel URLs which bugs some of the clients.


Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[1DMF]

So you think it's a bug in the cpanel management interface?

That's a bit worrying!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[ChrisHirst]

So you think it's a bug in the cpanel management interface?

Hopefully not, main supect currently is compromised passwords, after requesting the user names and passwords the affected clients are using, it transpires some of our them seem to be of the opinion that adding a '1' or a '0' to the default cPanel username and changing the password to that, is a "secure password", the 12 character upper case, lower case, numerals and symbols one being "too difficult to type in".

Think the "change password" option in cPanel may go mysteriously missing from the menu sometime in the next couple of days.


Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[1DMF]

lol - I know that feeling, our members extranet has no way of changing the system generated password and it's going to stay that way!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta