Tag Info

Hot answers tagged

54

If the server is configured correctly, you cannot download a PHP file. It will be executed when called via the webserver. The only way to see what it does is to gain access to the server via SSH or FTP or some other method. This is because PHP is a serverside language, all the actions are performed on the server, then the result is sent to your browser ...


8

This crossdomain.xml policy file revokes all protection that the Same Origin Policy provides. I use the crossdomain proof of concept tool, which has a simple interface to test SOP bypasses.


6

As others have said, the PHP file is executed server-side, unless the server is so badly set up that it will simply serve the source. If you would like to examine what is sent to your client without the possibility of it doing anything untoward, use a text editor like Notepad to open the URL. That is, use File → Open but open the URL rather than a real ...


5

As with all things in security, using HTTPS is a trade-off. You're trading some performance and potentially customer inconvenienace for improved security and other possible benefits (for example google boosting the ratings of SSL enabled sites). Only you can answer whether that's worth it, as only you know what your site does and whether the trade-off is ...


5

You are correct that this is not possible without mis-configuration or security vulnerabilities that allow it. Generally, the most likely culprits when it comes to coughing up application code are commented out code, backup files that have extensions allowing them to be delivered directly to clients without processing, and probably more likely that all ...


5

There's a misconception or two in your question. As a message (file, etc.) hash, MD5 is not insecure because of the “ability to brute force and pick up the result”. Cryptographic hashes are supposed to have three security properties: One way: Given a hash, it is infeasible to find a message with that hash. Integrity: given a message, it is infeasible to ...


4

But that means that XSS is not for cookie stealing anymore? In short, no, XSS isn't used to steal cookies when this flag is set. The longer answer is that modern browsers support the HttpOnly flag on cookies. This flag can be set when the server sends a Set-Cookie header to the browser to keep document.cookie from getting the contents of cookies. It is ...


3

In one sentence: you have to trust the client to use TLS and generally protect the token. Like many token systems, JWT relies on the client to secure its token. Clients are already required to maintain credentials needed for authentication (eg: passwords) so this is not a radically different concept. Furthermore, JWTs typically have a much shorter ...


3

On the surface this sounds like a fine idea - if you're trying to provide a buffer against: Version control (git / svn hosting) compromise Theft of a physical machine containing the codebase / credentials Malware on one of your developers machines leaking the credentials in some way. Any other way in which the files containing credentials are stolen by an ...


3

I think the vulnerabilities are the same for all Internet-accessible servers, the only increase in risk is that the code exposes some specific information about how to interface with it, and because it is "in code" the programmer might not think to protect it as well as they otherwise might for a server that is explicitly advertised.


3

If the web server you are using is correctly configured, you don't have to worry about the actual uninterpreted ASP / PHP files themselves being served out (unless of course the attacker is exploiting a vulnerability somewhere, as you pointed out). If you're especially concerned about code theft it's probably more useful to think about other, more likely ...


3

Question 1 Question 1: Are there any obvious security flaws in that scheme (except that the attacker can access the data of all logged-in users)? Proposed scheme: Registration The user digests a password key P from the plain-text password p using SHA 256 The user sends this key over a secure connection to the server The server generates a random ...


3

If implemented correctly, HttpOnly prevents an attacker stealing the cookie. However HttpOnly feature can be bypassed in certain versions of some browsers and web servers. Take a look: https://lwn.net/Articles/646891/ https://www.youtube.com/watch?v=jrKOdWPZtAg https://bugzilla.redhat.com/show_bug.cgi?id=1222923 So in summary HttpOnly makes things ...


2

As of 2015 this is how you prevent your website from sending the Referer header: Just add this to the head section of the web page: <meta name="referrer" content="no-referrer" /> This works both for links and for Ajax requests made by JavaScript code on the page. Other valid meta options include: <meta name="referrer" content="unsafe-url" ...


2

Well, the server HAS to set this flag on the cookie, if it doesn't, client side scripts such as javascript snippets in a XSS style attack can access the cookie contents. Also, you might want to look at XST(Cross-Site Tracing) which i believe can bypass this flag and allow stealing cookies in some scenarios. From the wiki page for it: Tagging a cookie ...


2

You just found the issue, you didn't take advantage of the flaw and never intended to do harm (I assume you wouldn't do any harm to your friends). However, every company should be happy if you report the issue to them. Big companies like Twitter or Facebook even pay nice bounties for this. You might check out HackerOne if the company you are talking ...


2

Ask the owner of the information if they authorize the request. As Neil Smithline points out in his excellent answer to this question, the RFCs on JWT, OAuth, and many other token-based authentication systems rely on the end user maintaining the secrecy of their token. For me personally, this is a hard pill to swallow: a lot of end users don't understand ...


2

This depends on the type of web application and the features it contains, so we'd need more information to provide more specific feedback. However, from a general information security standpoint, make sure to log anything that relates to: confidentiality integrity availability e.g. authentication attempts (both successful and faillures!), user x ...


2

With modern Intel CPU's (and we're talking 5-7 years now...) there is no significant performance hit on the computation involved in an SSL connection. So - from a performance perspective there is no reason not to use SSL everywhere. Another caveat is the vulnerability of mixed content on your page. You should not be referencing HTTP resources on an ...


2

Sorry to rain on everyone's parade but this is really bad idea. (Nice thread btw! but right answers to wrong question. You have created a complex DIY crytography scheme which is a bad idea in general since your implementation will introduce more vulnerabilities then you have today. Take a step back and do a threat analysis. Start with assets - how ...


1

This leads to question #1: the Javascript code sent to the browser must contain the shared secret. So the shared secret is not very secret, is it? So how can we consider this a secure method of authentication? If you study the documentation of the Challenge Response Authentication with WAMP you should notice the following information: The client and ...


1

Its not clear to me if you're using Azure VM or PaaS but you may want to consider a flow using SAS tokens. On Azure you have a built-in mechanism called SAS -shared access signatures. You can read more about SAS here https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-shared-access-signature-part-1/ Your flow would be like this Pass ...


1

This will greatly depends on the usage you intend for the honeypot. There was another discussion linking to an interesting document highlighting legal consequences of honeypot usage. Indeed, advertising the honeypot the wrong way might lead you in hot waters from a legal perspective. Some specific honeypots implementation will therefore not be implemented ...


1

FCrDNS should only be required when the end user needs to properly identify itself with a domain or organization, commonly used for email where the from address header should match the PTR of the sending IP (IPv4 or IPv6 Address). Actually Tom, if you notice Google requires IPv6 initiated email connections to have a proper RDNS, so that's out. The fact is ...


1

This makes (somewhat) sure that you really are the user associated with the account, you should at least know what email address was used to create the account. Filling the email address automatically could already give an attacker the opportunity to get all the email addresses in the database, just request a new password for every account you can think of. ...


1

As @Philipp states, any URI may have a query string, regardless of the HTTP method (GET, POST, PUT, ...) it is used with. The RFCs do not, in general, explicitly discuss query strings, even when discussing methods like GET where we expect to see them. A rare explicit mention is in RFC 2068: some applications have traditionally used GETs and HEADs ...


1

According to RFC 3986 - Uniform Resource Identifier the query component is allowed for any URI regardless of the used protocol. That means it is not only allowed for any HTTP method (what you call "request type"), but even for any other protocol which uses URIs, like for example ftp.


1

You can opt for protection from a scrubbing service by placing your applications behind a packet scrubbing service like Akamai or CloudFlare. These CDN's will take the hit for you normally before it reaches you.


1

No, you can't, because PHP is executed on the server. End. There is no need to get the code, because it's not executed on your computer, so there is no security risk for you. PHP will serve websites like any other, so that there is no PHP-specific answer. If you're interesed in a general answer, have a look at How do I safely inspect a suspicious email ...



Only top voted, non community-wiki answers of a minimum length are eligible