o/ manoj 


1.1) Exposing the PHP configuration will enable hackers to gain information, that may aid them in but not limited to: Privilege escalation, uploading files (by using the exposed information), get detailed information about vulnerable plugins (rare), see disabled functions and classes (useful when many functions are disabled), etc.

1.2) Minor bug when it's phpinfo(); and php.ini - It should be fixed though! 

1.3) Not alone, the attacker(s) need an entry-point. If there's no user-input available at all, and the server is "secure", the information leaked / exposed, will do little good at the current time. (Later on, it could prove useful but it may also change.)

1.4) Incorrect. HTAccess files are mostly used for SEO nowadays, and custom 404 pages, along with of course, directories that requires a user and password. HTAccess can also control which files, are executed as what. I saw a backdoor not long ago, that made .lol (a file extension), become executed as .php .This requires code execution on the server already of course. .htaccess files are and shouldn't be readable directly via the website either. (The webserver should return a 403 forbidden error.)

1.5) Please refer to 1.4, as there's no "direct" attacks on .htaccess files. All you can do if you have access to the server, as in code execution, is to alter it if you have user privileges to do this.

--------------------------------------------------------

2.1) Good and bad.
Good: They're secure from the bad guys.
Bad: If they become too good, we loose our jobs  (What a dilemma? Even though, isn't it our goal to create a perfect Internet with no security holes, if it was possible? But then again, some infosec people, are only in for the money. If everything was 100% secure though it is not possible, as we're humans and we make errors, I would probably find another hobby such as engineering.)

2.2) It might, it depends on if the developers of the applications are getting smarter, but also receive the education to write proper code.

2.3) Yes, we've already seen Clickjacking, and many other types of jacking the recent years. Along with CSRF attacks too, and so forth. The breed for new attacks, also relies on how web applications evolve, along with their programming languages and developers behind. (And of course, the hackers researching the security.)

2.4) Read the Web Application Hacker's Handbook vol. II (2), it should be out soon  Besides that, I'd recommend all the other things I've recommended you already, though not visible in this post. 

Thanks maxe,It seems unless a attacker finds a critical bug,these configuration exposure should not pose much risk to the particular target,but what i am thinking was,if one of the web-site hosted on a target server has the configuration leak and another site in the shared server has the bug through which an attacker can obtain shell,then this issue will become HOT...


I also asked these same question in some other boards and what people said me "sql wont completely die like the other breed of attacks as we are going not going to abolish the use of database in next generation" and regarding xss they said "xss has not been seen as a  very serious threat by the web-browser developers,so in the future this kind of attack may be reduced,but it wont die like the other attacks"

And yeah i am still following all of your advices ,that is why lot of questions are popping up in my head daily


And i am not sure about the development field,but i would definitely like to ask you this,
secure programmers vs traditional programmers
even tough programmers from both the sides are knowledgable
 who are developing the most  vendor specific web-applications that we are using today ?

And thanks for answering me maxe ,I got lot more to ask you

Or they make fixes without testing it